Joe Conway <mail@joeconway.com> writes:
> On 10/11/2011 02:07 PM, Kevin Grittner wrote:
>> I would certainly vote for enforcing on the SET and not causing an
>> error on the attempt to change the limit. ...
>> 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.
It's not the same thing. Those operations are documented as providing
the initial default value for subsequently-started sessions. The
proposed change in limit values is different because the GUC range
limits have always before been immutable and continuously enforced
for the life of a database instance.
It may be that Kevin's proposal is adequate. But I find that far
from obvious. The trend of everything we've done with GUC for the last
ten years is to cause settings changes to apply immediately on-demand
and without "oh, but that's obvious if you know the implementation"
special cases. I'm not real sure why this should get a free exemption
from that expectation ... or to put it more plainly, I *am* sure that
we'll be expected to fix it later, just like we had to fix the behavior
around removal of postgresql.conf entries, and some other things that
people didn't find as obvious as all that.
regards, tom lane
