On 10/11/2011 02:07 PM, Kevin Grittner wrote: > Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
