Re: dblink vs SQL/MED

Joe Conway wrote:
> Peter Eisentraut wrote:
>> 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.

The attached now includes documentation and regression test changes. It
also includes the refactoring to pull dblink_send_query() out of
dblink_record_internal() and the fix for the bug reported by Oleksiy
Shchukin.

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

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?

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

Thanks,

Joe