On Fri, Jul 22, 2011 at 12:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
