Re: SQL/MED compatible connection manager

On Thu, Jan 01, 2009 at 11:10:38PM +0200, Martin Pihlak wrote:
> 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.

The connection string could be pretty different if it's not a
PostgreSQL database, so +1 on the SRF option :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate