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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to