Re: SET variable - Permission issues

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(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 15:05:18
Message-ID: 201110111505.p9BF5Ip16578@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jun Ishiduka 2011-10-11 15:17:27 Re: Online base backup from the hot-standby
Previous Message Bruce Momjian 2011-10-11 14:29:51 Re: unite recovery.conf and postgresql.conf