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

Re: dblink vs SQL/MED

From: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-04 20:13:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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:

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.


In response to


pgsql-hackers by date

Next:From: Joe ConwayDate: 2009-01-04 20:34:14
Subject: dblink vs SQL/MED - security and implementation details
Previous:From: Alvaro HerreraDate: 2009-01-04 18:11:47
Subject: Re: parallel restore

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