I have been thinking that we are setting up the foreign-data wrapper dummies
wrongly.
Eventually, the postgresql_fdw library should contain an implementation that
actually connects to a PostgreSQL database and does useful things (dblink
replacement, basically). Right now, we are proposing to use it as connection
information storage. But I think that might get us in trouble later.
Loading a fully implemented postgresql_fdw might do significant work, which
you don't really want when you are just querying the connection parameters.
(This is not completely theoretical: Firing up libpq might do zeroconf
queries or in the far future even connection pooling.) We have conflicting
use cases there: We are loading up a library that we don't intend to use.
I think the proper approach is to separate these concerns: Have one FDW
implementation that (eventually) does real PostgreSQL connectivity, and one
that just does parameter storage. We could name the latter postgresql_dummy,
but I also have another idea: We could just use the dummy wrapper and set an
option for the foreign data wrapper that tells what options are valid. That
is, you would say
CREATE FOREIGN DATA WRAPPER postgresql_dummy LIBRARY 'dummy_fdw' LANGUAGE C
OPTIONS (valid_options '{host,port,dbname,user,password...}');
CREATE SERVER server1 FOREIGN DATA WRAPPER postgresql_dummy OPTIONS
(host 'localhost');
CREATE USER MAPPING FOR current_user SERVER server1 OPTIONS
(password 'seKret');
That way, you would have more flexibility, less code, and less potential
conflicts in the future.
Comments?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
