Re: SQL/MED compatible connection manager

Peter Eisentraut wrote:
>> 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.
>

Lets say a backend has the library loaded and the FDW function pointers
already initialized. Now the FDW library file is upgraded, and the user
issues a LOAD command to reload the library. The library is reloaded, but
the function pointers never get updated. Attempt to use the FDW functions
most likely crashes the server.

The options are:
- always look up functions immediately before use (performance penalty)
- use _PG_fini callback to register FDW unloads (needs cooperating library)
- document that reloading is not supported (ie. this is a feature)
- just ignore it, as there are probably a dozen more ways a superuser can
crash the server.

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

Hmm, I just realized that there are only OID variants of those -- indeed
those are not very useful. If names were used instead, the functions would
be a lot more useful. Especially so, if FDW doesn't provide connection
lookup.

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

It'd make more sense if we changed the name to pg_get_datasource ;)

We could make the pg_get_remote_connection_info Postgres specific -- in
this case it would be changed to return just the connect string text. NULL
for the other wrappers -- for these use the pg_get*options to construct
the connect strings. Comments?

One more thing just occured to me -- the dummy and postgresql wrappers are
currently installed by initdb. The majority of installations will probably
never use them. So I think it would make sense to ship with no predefined
FDW-s.

regards,
Martin