Peter Eisentraut wrote:
> Looks very good, please continue.
>
Thanks, will do :)
> 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',
[snip]
> If I read this right, SQL/MED requires option names to be unique for a
> server. To this needs to be rethought.
>
Indeed, seems that I somehow managed to miss that. Additionally, according
to the standard the options should be specified as <name> <value>, instead
of <name> = <value>. Plus the possibility to alter individual options.
I'll look into that.
Updated the wiki to use unique option names.
> 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');
The purpouse of the connection lookup function is to compose the the actual
connection string from generic options (adds user mapping if needed). This
aims to make it easier for the clients to perform connection lookups. The
idea is that the connection string should be composed by the foreign data
wrapper, instead of letting each client have it's own interpretation of the
options. Though, it is still possible to query the options directly.
> And similarly, pg_get_user_mapping_options() is equivalent to
> information_schema.user_mapping_options.
>
Hmm, the options are stored as text[], these need to be transformed to be
usable in the views. Seems that additional functions for foreign data wrapper
and server options are also needed. Will add those, along with the
information_schema views.
regards,
Martin