Greg Stark <stark@enterprisedb.com> writes:
> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>
>> On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
>>> This is as documented (although I want to add a line to SET ROLE docs)
>>> but is it the behavior we want? �I for one would like SET ROLE to change
>>> runtime configs.
> Well for one thing pg_dump uses SET ROLE extensively and it sets
> parameters assuming they'll stay set
I think this is going to make the already-tricky semantics of GUC
variables completely impossible. Per-user settings normally establish
the session's RESET values of the variables and can be overridden (for
the session or just for a transaction) by explicit SET. If the latter
remains true it'd fix Greg's concern about pg_dump, but it's just
mind-bending to think about what RESET means if we try to put this in.
Assume we've done ALTER ROLE SET foo = something for our login
role and ALTER ROLE x SET foo = somethingelse:
start psql
-- foo = something, presumably
SET foo = other;
SET ROLE x;
-- foo still = other, presumably
RESET foo; -- now what is foo?
(if your answer is "somethingelse", justify this in terms of the
documented behavior of RESET: restore to the session-start value.)
RESET ROLE; -- now what is foo?
(ie, does this action in itself change foo, and if so why?)
Also, with all the whining I've seen in the past few days about not
making application-breaking incompatible changes, it would seem
appropriate to have a GUC to control whether we have this behavior or
the old one. Discuss the implications of changing such a GUC partway
through this sequence. For extra credit, explain what would happen if
it were set via ALTER ROLE SET for one role or the other.
In short: -1 from me.
regards, tom lane
