Re: SET variable - Permission issues

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "Joe Conway" <mail(at)joeconway(dot)com>, <pgsql-hackers(at)postgresql(dot)org>,"Josh" <josh(at)schemaverse(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SET variable - Permission issues
Date: 2011-10-11 18:53:00
Message-ID: 4E944A3C0200002500041DF0@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Kevin Grittner wrote:
>> Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-11 18:54:17 Re: Index only scan paving the way for "auto" clustered tables?
Previous Message Merlin Moncure 2011-10-11 18:48:39 Re: Proposal: casts row to array and array to row