Re: SQL/MED dummy vs postgresql wrapper

Peter Eisentraut wrote:

> 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.  

Actually the connection lookup doesn't even require loading the FDW
library. It does so at the moment because GetForeignDataWrapper() loads
the library automatically.

> 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...}');
> 

How about extending the syntax by adding validator function(s) instead (similar
to CREATE LANGUAGE)? For instance for postgresql wrapper we might want to check
that a password is provided for a user mapping. The default validator for postgres
wrapper would be supplied, but nothing prevents the user from replacing it with
custom validator. Additionally it is possible to run-the same validator by
connection lookup, so that the connection can be sanity checked.

Something like:

CREATE FOREIGN DATA WRAPPER postgresql LIBRARY 'dummy_fdw' LANGUAGE CVALIDATOR postgresql_fdw_validator;

It is also possible to guess the validator function name from the FDW name.

Additionally, if we are taking this route, it no longer makes sense to provide
the empty shared libraries. We could drop the shared libraries altogether and
loosen the syntax to:

CREATE FOREIGN DATA WRAPPER postgresql VALIDATOR postgresql_fdw_validator;
or just:
CREATE FOREIGN DATA WRAPPER postgresql;

regards,
Martin