Re: SQL/MED compatible connection manager

From: David Fetter <david(at)fetter(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED compatible connection manager
Date: 2009-03-04 15:13:51
Message-ID: 20090304151351.GT19267@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 04, 2009 at 03:26:36PM +0200, Peter Eisentraut wrote:
> Martin Pihlak wrote:
>> Proposal attached. This adds two C functions:
>>
>> List *GetForeignConnectionOptions(Oid serverid, Oid userid);
>> char *GetForeignConnectionString(Oid serverid, Oid userid);
>>
>> One for obtaining all of the connection related options as a list,
>> and another for transforming these options into a libpq conninfo
>> string. The latter should be useful for dblink (although the
>> userid and serverid need to be obtained first).
>>
>> On top of those there are two SQL accessible functions:
>>
>> pg_foreign_connection_options(server name, user name =
>> current_user, OUT option_class text, OUT option_name text, OUT
>> option_value text);
>>
>> pg_foreign_connection_string(server name, user name =
>> current_user);
>>
>> These should initially be restricted from ordinary users -- grant
>> explicitly if the user should see the connect strings.
>
> Back to this one ...
>
> I have been thinking about this for a great while now. I am not yet
> comfortable with how we manage the access rights here. We have
> restricted access to the user mappings catalog to hide passwords,
> but it is not entirely clear why a password must be stored in a
> user mapping. It could also be stored with a server, if we only
> want to use one global connection for everybody.
>
> I think the proper way to handle it might be to introduce a new
> privilege type -- call it SELECT if you like -- that determines
> specifically whether you can *see* the options of a foreign-data
> wrapper, foreign server, or user mapping, respectively. As opposed
> to USAGE, which means you can use the object for connecting (in the
> future). This might have other uses: The owner of a server might
> want to hide the host name, but still let you connect.
>
> Comments?

This could have a more general usage, too. Does SQL:2008 have
anything to say about such a capability, or is it already in the
column-level privileges, or...?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2009-03-04 15:14:41 Re: SYNONYMs revisited
Previous Message Tom Lane 2009-03-04 15:11:25 Re: building pg_dump doesn't work