Re: Should SET ROLE inherit config params? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should SET ROLE inherit config params?
Date
Msg-id 603c8f070903270925j26a71b19taece3eba63589aaa@mail.gmail.com
Whole thread Raw
In response to Re: Should SET ROLE inherit config params?  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Should SET ROLE inherit config params?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
>
>> I was just noticing that doing SET ROLE changes the current session's
>> priviledges, but not any runtime configuration parameters (like work_mem
>> or statement_timeout) associated with the new role.
>>
>> 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.
>
> Thinking some more about the requirements for this and various
> objections.
>
> I'm guessing that there's a small cluster of parameters you want to
> alter using this. It seems easier to think about those parameters and to
> look at ways of managing those. Perhaps what we need is not parameters
> on roles, but a related concept: profiles.

I think this is way over-engineered.  All we really need here is a
command along the lines of RESET ALL AS CURRENT USER that gives every
GUC the value it would have had if you logged in under the current
user's account.  Simple, clean, no new keywords.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Potential problem with HOT and indexes?
Next
From: Robert Haas
Date:
Subject: Re: SSL over Unix-domain sockets