Bruce Momjian <br...@momjian.us> wrote: > Kevin Grittner wrote: >> Joe Conway <m...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers