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

Re: dblink vs SQL/MED

From: Joe Conway <mail(at)joeconway(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: dblink vs SQL/MED
Date: 2009-01-02 22:39:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?



Attachment: dblink.sqlmed.3.patch
Description: text/x-patch (3.9 KB)

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2009-01-02 22:48:15
Subject: Re: Significantly larger toast tables on 8.4?
Previous:From: Robert HaasDate: 2009-01-02 22:36:31
Subject: Re: posix_fadvise v22

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