dblink vs SQL/MED - security and implementation details

(changed the subject to hopefully get a few more eyes looking at this 
thread)

Martin Pihlak wrote:
> 
> I'd vote for allowing aribitrary connect strings -- ordinary users cannot
> create servers and user mappings unless explicitly granted the privileges.
> It probably should be noted in the documentation that allowing ordinary
> users to create user mappings enables the use of postgres .pgpass file.
> Not sure where to put this at the moment.

I'm mainly concerned about re-opening security holes that we spent a lot 
of time debating and subsequently closing. I suspect if we assume that 
any FDW-derived connect string can bypass the checks we put in place, we 
will regret it later. But I'm open to arguments on both sides...

>>> 2. It seems like get_connect_string() is generically useful to any
>>>    client of postgresql_fdw.c -- should it go there instead of dblink?
>> I'm pretty sure get_connect_string() should be moved to postgresql_fdw.c
>> -- objections?
> 
> There is some discussion in another thread about this:
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01875.php
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg00021.php
> 
> The initial approach was to let each foreign data wrapper provide its own
> connection string/list builder function. Latest is to provide the lookup
> functions in foreign.c, and use the same functions for all the different
> fdw's. I was about to implement those but got distracted. Will resume now.

It seems to me that get_connect_string() (or whatever we decide to call 
it), is very libpq specific, and therefore belongs with postgresql_fdw.c 
rather than foreign.c. But if we can't reach a consensus there is no 
harm in leaving it as a dblink.c specific static function either.

Joe