Implementation of external data management #1158

[paradox1307]

Link to RFC - Distributed queries (Management of External Data) proposal

[paradox1307]

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

[sim1984]

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.

[sim1984]

May be RDB$FOREIGN_OPTION_TYPE ?

[paradox1307]

Yes, corrected.

[sim1984]

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

[paradox1307]

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.

[sim1984]

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.

[paradox1307]

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.

[sim1984]

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>
}

[paradox1307]

Corrected, thanks.

[sim1984]

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]

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

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

[sim1984]

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

[sim1984]

Where READONLY option?

[paradox1307]

Description added.

[sim1984]

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';