Joe Conway wrote:
>> Two specific questions on this approach:
>> 1. This implies that the exact same dblink_connstr_check() is performed
>> on a predefined foreign server and user mapping as a raw connstr --
>> is this desireable? I'm not entirely clear on the intended purpose
>> and use of foreign data wrappers yet.
>
> On the one hand, why be any less stringent on an fdw server than any
> other connect string? But on the other hand, the fdw server definition
> has supposedly been vetted by a superuser. Any thoughts of this?
>
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.
>> 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.
regards,
Martin
