Re: Should SET ROLE inherit config params?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Should SET ROLE inherit config params?
Дата
Msg-id 603c8f070903270925j26a71b19taece3eba63589aaa@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should SET ROLE inherit config params?  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Should SET ROLE inherit config params?
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Potential problem with HOT and indexes?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: SSL over Unix-domain sockets