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
