Re: SET variable - Permission issues

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: SET variable - Permission issues
Дата
Msg-id 4E944A3C0200002500041DF0@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: SET variable - Permission issues  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: SET variable - Permission issues
Re: SET variable - Permission issues
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> wrote:
> Kevin Grittner wrote:
>> Joe Conway <mail@joeconway.com> wrote:
>>> On 10/10/2011 01:52 PM, Gurjeet Singh wrote:
>>  
>>>> ALTER USER novice SET MIN_VAL OF statement_timeout TO '1';
>>>> -- So that the user cannot turn off the timeout
>>>> 
>>>> ALTER DATABASE super_reliable SET ENUM_VALS OF
>>>>   synchronous_commit TO 'on';
>>>> -- So that the user cannot change the synchronicity of
>>>> transactions against this database.
>>> 
>>> I like this better than GRANT/REVOKE on SET.
>>  
>> +1
>>  
>> I would really like a way to prevent normal users from switching
>> from the default transaction isolation level I set.  This seems
>> like a good way to do that.  Putting sane bounds on some other
>> settings, more to protect against the accidental bad settings
>> than malicious mischief, would be a good thing, too.
> 
> Is this a TODO?  We might not want to make work_mem SUSET, but it
> would allow administrators to control this.
Well, we've identified a few people who like the idea, but I'm not
sure we have the degree of consensus we normally look for before
putting something on the TODO list.  After the discussion on this
thread, are there still any *objections* to allowing bounds or
subsets to be SUSET to limit GUC values more strictly than the
limits hard-coded in C?
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Proposal: casts row to array and array to row
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Index only scan paving the way for "auto" clustered tables?