Re: SET variable - Permission issues - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SET variable - Permission issues
Date
Msg-id 4E944A3C0200002500041DF0@gw.wicourts.gov
Whole thread Raw
In response to Re: SET variable - Permission issues  (Bruce Momjian <bruce@momjian.us>)
Responses Re: SET variable - Permission issues  (Joe Conway <mail@joeconway.com>)
Re: SET variable - Permission issues  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List 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 by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Proposal: casts row to array and array to row
Next
From: Robert Haas
Date:
Subject: Re: Index only scan paving the way for "auto" clustered tables?