From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Josh <josh(at)schemaverse(dot)com> |
Subject: | Re: SET variable - Permission issues |
Date: | 2011-10-11 23:06:22 |
Message-ID: | 4E94CBEE.2030903@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/11/2011 02:07 PM, Kevin Grittner wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> This isn't exactly a trivial matter. What happens for instance if
>> you try to change the limit, and there are already active values
>> outside the limit in some processes?
>
> I would certainly vote for enforcing on the SET and not causing an
> error on the attempt to change the limit. (Maybe a notice?) At the
> time they set the GUC, they were allowed to do so. It's a bit like
> revoking a user's right to create a table in a schema -- what if
> they've already done so? You leave the table and you don't let them
> create another.
>
> What problems do you see with that?
Yeah, I don't know why it need be handled any different than say
ALTER DATABASE foo SET config_param TO value
or
ALTER ROLE foo SET config_param TO value
These cases do not effect already existing processes either.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-10-11 23:39:17 | Re: Dumping roles improvements? |
Previous Message | Bruce Momjian | 2011-10-11 22:07:04 | Re: Formatting Curmudgeons WAS: MMAP Buffers |