Skip to content

Implementation of external data management #1158#8759

Draft
paradox1307 wants to merge 17 commits intoFirebirdSQL:masterfrom
paradox1307:master_sql_med
Draft

Implementation of external data management #1158#8759
paradox1307 wants to merge 17 commits intoFirebirdSQL:masterfrom
paradox1307:master_sql_med

Conversation

@paradox1307
Copy link
Contributor

@paradox1307
Copy link
Contributor Author

This is a draft implementation of external data management (SQL:MED). It will be improved after the metacache #7954 is merged.

@dyemanov dyemanov marked this pull request as draft September 30, 2025 07:34
@dyemanov dyemanov self-requested a review September 30, 2025 07:35
@sim1984
Copy link
Contributor

sim1984 commented Sep 30, 2025

Are there any restrictions for users/roles on using foreign servers? I think there should be. That is, we should have something like:

GRANT USAGE ON SERVER <server_name>
TO <grantee_list> [WITH GRANT OPTION]
[{GRANTED BY | AS} [USER] <grantor>];

REVOKE [GRANT OPTION FOR]
USAGE ON SERVER <server_name>
FROM <grantee_list>
[{GRANTED BY | AS} [USER] <grantor>];

This is important, especially if the foreign server stores authentication data. Not every authenticated user should be able to use it in an EXECUTE STATEMENT.

| RDB$FOREIGN_SERVER_NAME | CHAR \(63\) | The foreign server name |
| RDB$FOREIGN_OPTION_NAME | CHAR \(63\) | Option name |
| RDB$FOREIGN_OPTION_VALUE | VARCHAR \(32765\) | Option value |
| RDB$OWNER_NAME | SHORT | Option type |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be RDB$FOREIGN_OPTION_TYPE ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, corrected.

continue;

buffer.append(option.first.c_str());
buffer.append(";");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there a semicolon ; here? I would have expected an equals symbol =.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was that option names and option values follow each other and there is no sense in adding a special character to separate them, i.e. option_1_name;option_1_value;option_2_name;option_2_value;.... If this is confusing, it can be changed to something else.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, this approach will work, provided that each option requires a value. In this case, we eliminate the possibility of passing only the option name as a flag.

GRANT USAGE ON FOREIGN SERVER <server_name>
TO <grantee_list> [WITH GRANT OPTION]
[{GRANTED BY | AS} [USER] <grantor>];

REVOKE [GRANT OPTION FOR]
USAGE ON FOREIGN SERVER <server_name>
FROM <grantee_list>
[{GRANTED BY | AS} [USER] <grantor>];
@paradox1307
Copy link
Contributor Author

Are there any restrictions for users/roles on using foreign servers? I think there should be.

Yes, there should be restrictions on using foreign servers. The MED standard requires GRANT/REVOKE USAGE ON FOREIGN SERVER. Implemented in df133b1 . Please note that when creating foreign tables and user mappings, USAGE checks have also been added, as required by the standard.

[[DROP] FOREIGN DATA WRAPPER | [DROP] USING PLUGIN <provider(plugin)>] [OPTIONS(<option> [, <option> ...] )]
<option> ::= {
[DROP] <option name> [= 'value']
| [DROP] <option name> [{FILE | ENV}] ['value'] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This description confuses people because it's unclear what's required and what's optional. A better explanation would be:

ALTER SERVER <foreign server name>
        [[DROP] {FOREIGN DATA WRAPPER | USING PLUGIN} <provider(plugin)>] 
        [OPTIONS (<option> [, <option> ...] )]

<option> ::= {
          <option name> = 'value'
        | <option name> [{FILE | ENV}] 'value' 
        | DROP <option name>
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrected, thanks.

@sim1984
Copy link
Contributor

sim1984 commented Oct 29, 2025

Are there any restrictions for users/roles on using foreign servers? I think there should be.

Yes, there should be restrictions on using foreign servers. The MED standard requires GRANT/REVOKE USAGE ON FOREIGN SERVER. Implemented in df133b1 . Please note that when creating foreign tables and user mappings, USAGE checks have also been added, as required by the standard.

This should be described in the README.MED.md documentation.

@paradox1307
Copy link
Contributor Author

This should be described in the README.MED.md documentation.

Added description GRANT/REVOKE USAGE ON FOREIGN SERVER to the documentation.

@sim1984
Copy link
Contributor

sim1984 commented Mar 16, 2026

I will join the testing with my ODBCEngine/MySQLEngine providers when the Windows builds are ready.

* TABLE_NAME - name of the table on the foreign server.
General column options are:
* COLUMN_NAME - the name of the column in the foreign table;
* PRIMARY_KEY - an identifier explicitly specifying that the column is used in the primary key.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where READONLY option?

@sim1984
Copy link
Contributor

sim1984 commented Mar 20, 2026

For consistency, it would be nice to add the ability to save user comments like for other database objects.

This is how it should look for foreign servers.

COMMENT ON SERVER <foreign server name> IS 'text';

I can't imagine how this might look for user mappings, since they don't have simple names.

For foreign tables, it might look like this.

COMMENT ON FOREIGN TABLE <table name> IS 'text';
COMMENT ON COLUMN <table name>.<column_name> IS 'text';

Perhaps the additional COMMENT ON FOREIGN TABLE is unnecessary, and you could simply use

COMMENT ON TABLE <table name> IS 'text';

@paradox1307
Copy link
Contributor Author

For consistency, it would be nice to add the ability to save user comments like for other database objects.

Agree. I'll add the ability to save comments for foreign servers and tables.

I can't imagine how this might look for user mappings, since they don't have simple names.

Maybe:

COMMENT ON USER MAPPING FOR <user> SERVER <server_name> IS 'text';

?

@sim1984
Copy link
Contributor

sim1984 commented Mar 20, 2026

Maybe:

COMMENT ON USER MAPPING FOR <user> SERVER <server_name> IS 'text';

?

OK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants