Re: SQL/MED compatible connection manager

Martin Pihlak wrote:
> Here's another revision of the connection manager. This adds:
> * reference documentation
> * psql, tab-completion, \dw, \dr, \dm commands.
> * pg_dump support
>
> Still todo:
> * more comprehensive regression tests
> * introductory documentation
> * dblink support
>
> I hope to finish these items during next week, and remove the WIP
> status then.

Looks very good, please continue.

Most of this is straight out of the standard, so there isn't much to
discuss on the interfaces. I have two small things to wonder about:

On your wiki page, you have this example:

CREATE SERVER userdb TYPE 'plproxy_cluster'
FOREIGN DATA WRAPPER plproxy
OPTIONS (
server='dbname=userdb_p0 host=127.0.0.1 port=6000',
server='dbname=userdb_p1 host=127.0.0.1 port=6000',
server='dbname=userdb_p2 host=127.0.0.1 port=6000',
server='dbname=userdb_p3 host=127.0.0.1 port=6000',
connection_lifetime=3600
);

If I read this right, SQL/MED requires option names to be unique for a
server. To this needs to be rethought.

Do we really need the function pg_get_remote_connection_info()? This
could be done directly with the information schema. E.g., your example

SELECT * FROM pg_get_remote_connection_info('userdb');

appears to be the same as

SELECT option_name, option_value
FROM information_schema.foreign_server_options
WHERE foreign_server_name = 'userdb';

This view also appears to have the necessary access control provisions.

And similarly, pg_get_user_mapping_options() is equivalent to
information_schema.user_mapping_options.