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