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_p0host=127.0.0.1 port=6000',        server='dbname=userdb_p1 host=127.0.0.1 port=6000',
server='dbname=userdb_p2host=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.