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-03 22:31:31
Message-ID: 495FE743.1040907@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

Attachment: dblink.sqlmed.4.patch
Description: text/x-patch (18.5 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-01-03 22:45:44
Subject: Re: Significantly larger toast tables on 8.4?
Previous:From: Peter EisentrautDate: 2009-01-03 22:29:22
Subject: Re: Frames vs partitions: is SQL2008 completely insane?

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