Re: SQL/MED compatible connection manager

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?