Re: SQL/MED compatible connection manager

Martin Pihlak wrote:
> This is now fixed -- the option validation and connection lookup functions
> have been made optional. InitializeFDW and _PG_fini have been dropped,
> functions are looked up in GetForeignDataWrapperLibrary(). I decided not to
> worry too much about the function pointers getting stale due to library
> changes and reloads, as that requires some deliberate actions as a superuser.

I never understood that reload business complete anyway. If you think
there are issues at run time, they should be documented somewhere.

> I also added _pg prefixes to the non-standard functions so that these are not
> confused with the standard FDW functions.

Yes, I think something like that should be OK.

> PS. Would it be more convenient to use the ~user area at git.postgresql.org
> for review? I haven't requested a user account yet, but will do so if it
> simplifies the review. The patches would still be posted to list as well.

Well, maybe a month ago. ;-) We are getting pretty close to committing.

I am not satisfied with the custom SQL functions that you added:

| pg_get_foreign_data_wrapper_options(fdwid oid)
| pg_get_foreign_server_options(srvid oid)
| pg_get_user_mapping_options(umid oid)

I think these are basically just a way to parse apart {a=1,b=2} into a
table. We could get more bang out of it, if we provided one function
that can do that parsing for all of fdwoptions, srvoptions, umoptions,
reloptions, datconfig, useconfig, proconfig. (reloptions and *config
use different parsers internally, but maybe that is not so important for
this problem.)

The other thing that I am not settled on is the default FDW (I renamed
it to dummy). In principle, this thing should do nothing, so the source
file ought to empty. Well, _pg_validateOptionList *is* empty, but
_pg_GetConnectionInfo has an excuse implementation that makes me think
that the pg_get_remote_connection_info() function has a too specific
mission to be a general function. If we added, say, an XML-file FDW,
what sense would pg_get_remote_connection_info() make?

For the record, my current patch, which merges all your latest changes,
is attached.

I could offer, if it turns out to be possible, that I cut these
contentious parts out of the patch and commit the rest as soon as
possible, because I am growing weary of moving this big patch around. :-)