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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
