Re: Should SET ROLE inherit config params?

On Wed, Mar 11, 2009 at 9:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <stark(at)enterprisedb(dot)com> writes:
>> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.

Maybe it would make more sense to have some option to SET ROLE or some
separate command that resets all configuration parameters to the
values that they would have had, if you had only logged in as that
other user originally. I thought "RESET ALL" might do this, but it
seems not.

...Robert