Skip site navigation (1) Skip section navigation (2)

Re: SQL/MED compatible connection manager

From: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED compatible connection manager
Date: 2009-01-01 21:10:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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


If there are no objections, I'll whack those functions out, and bring the dblink
patch up to date.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-01-01 21:58:40
Subject: Re: Enable pl/python to return records based on multiple OUT params
Previous:From: Tom LaneDate: 2009-01-01 20:55:15
Subject: Re: posix_fadvise v22

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group