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?