Peter Eisentraut wrote:
> Well, what this function essentially does is a text transformation of the
> options, something like this:
>
> peter=# SELECT array_to_string(fdwoptions || srvoptions || umoptions, ' ')
> FROM pg_foreign_data_wrapper fdw, pg_foreign_server srv, pg_user_mappings um
> WHERE fdw.oid = srv.srvfdw AND srv.oid = um.srvid;
> array_to_string
> -----------------------------------------------------
> host=localhost port=5432 user=peter password=seKret
> (1 row)
>
> (You can enhance this with quoting etc., but that's the essence.)
Essentially yes. Additional things include USAGE check on the server and user
mapping lookup (use public if no explicit mapping is specified). Without those
I'm not really sure this deserves a separate function at all. The main goal
is to provide standard semantics for the connection lookup, so that dblink,
plproxy, pl rpc etc. would not have to reinvent it.
> So, we could add a function whose job it is to convert all options to a
> PostgreSQL connection string. I wouldn't worry about dealing with other
> wrappers specifically. They could still use the function, but the result
> would not make much sense.
>
This works for me. I'd implement this as a C function so it is directly
callable from other C modules.
Another option is to implement it as a SRF, similar to what was initially in the
dummy wrapper. Just return all of the options for fdw, server and user mapping.
This is probably worth doing if there are any users for this. So far I haven't
noticed any enthusiasm, so it might be better to start with just the connection
string.
> I would call it something like
>
> pg_postgresql_fdw_options_string(server, user) returns text
Hmm, it is probably a good idea to avoid the fdw abbreviation -- the term
"foreign data wrapper" is already confusing enough. My suggestion:
pg_foreign_server_conninfo(server)
pg_foreign_server_conninfo(server,user)
If there are no objections, I'll whack those functions out, and bring the dblink
patch up to date.
regards,
Martin