On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jul 22, 2011 at 12:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> In particular I find the following in SQL-MED:2008 4.14.1: >>> >>> NOTE 9 - Privileges granted on foreign tables are not privileges to use >>> the data constituting foreign tables, but privileges to use the >>> definitions of the foreign tables. The privileges to access the data >>> constituting the foreign tables are enforced by the foreign server, >>> based on the user mapping. Consequently, a request by an SQL-client to >>> access external data may raise exceptions. > >> I read that to mean that the remote side might chuck an error >> depending on the credentials used to connect. I don't read it to be >> saying that the local side is required to do anything in particular. > > Well, if you read it that way, then CREATE USER MAPPING with an empty > option set is a no-op: the behavior of the FDW would be the same whether > you'd executed it or not. Which doesn't seem to me to satisfy the > principle of least surprise, nor the letter of the spec.
I think what they're saying is that they expect the credentials to be stored in the user mapping. But that seems like a fairly silly requirement, since it's not difficult to imagine wanting all of your local users to connect to the remote side with the same set of credentials; or wanting, perhaps, to connect to some data source that doesn't even require credentials, like a CSV file. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
