On Fri, Jul 22, 2011 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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 ...
>
> But if you want that, you'd do CREATE USER MAPPING FOR PUBLIC. What
> disturbs me about this approach is that it'd have the effect of a public
> mapping with no options existing by default, and being in fact
> impossible to remove. Now, depending on what the FDW chooses to require
> in the way of options, that might not be insecure; but it sure seems
> like a foot-gun waiting to fire on somebody.
Maybe. On the other hand, I think there's a pretty strong usability
argument against the way it works right now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company