Re: dblink vs SQL/MED

Peter Eisentraut wrote:
> On Saturday 20 December 2008 19:33:17 Tom Lane wrote:
>> Peter wrote:
>>> SQL/MED catalog manipulation facilities
>>>
>>> This doesn't do any remote or external things yet, but it gives modules
>>> like plproxy and dblink a standardized and future-proof system for
>>> managing their connection information.
>> It seems this is a pile of pretty useless code, so far as the core
>> distribution is concerned, unless somebody fixes dblink to use it.
>> Is that on anyone's radar for 8.4?
>
> Martin had sent some code for that with his original patch series. I or
> someone can review that next.

Here is what I would propose (still needs documentation and regression
test changes, but wanted feedback first). I think it is better to keep
the changes to dblink very simple.

After looking for an already existing dblink rconn, the passed connstr
is checked to see if it matches a valid foreign data server prior to
being used as a connstr. If so, a connstr is constructed from the
foreign server and user mapping options (for current user). The
resulting connstr is then treated exactly as if it were one that was
passed directly to dblink.

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.
2. It seems like get_connect_string() is generically useful to any
client of postgresql_fdw.c -- should it go there instead of dblink?

Thanks,

Joe