On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jul 22, 2011 at 12:02 PM, Tom Lane <tgl@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