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.
