From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Should SET ROLE inherit config params? |
Date: | 2009-03-27 16:25:11 |
Message-ID: | 603c8f070903270925j26a71b19taece3eba63589aaa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 27, 2009 at 4:04 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-03-27 16:27:30 | Re: SSL over Unix-domain sockets |
Previous Message | Tom Lane | 2009-03-27 15:59:29 | Re: Potential problem with HOT and indexes? |