Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Date
Msg-id CA+TgmoYNSsesfaNVY0d05GEwuL-xsbxGQ37ZJaAQ6w-S3r__BA@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
List pgsql-hackers
On Wed, Apr 3, 2013 at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Apr 2, 2013 at 12:19 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> It's weird that SET LOCAL and SET SESSION actually *set* the value, and
>>> the second key word determines how long the setting will last.  SET
>>> PERSISTENT doesn't actually set the value.  I predict that this will be
>>> a new favorite help-it-doesn't-work FAQ.
>
>> I think this is another argument against this particular syntax.  I
>> have always thought that something along the lines of ALTER SYSTEM
>> would be more appropriate.  ALTER DATABASE .. SET and ALTER ROLE ..
>> SET don't change the value immediately either, and nobody gets
>> confused about that to my knowledge.  But I can see where SET
>> PERSISTENT could cause that sort of confusion.
>
> Yeah, I think I argued for using the SET syntax to start with, but
> I'm coming around to the position that SET PERSISTENT is too much
> unlike the behavior of other varieties of SET.  ALTER is sounding
> more attractive to me now.  Not sure about "ALTER SYSTEM" in particular
> though --- it's not clear that that has any real merit other than
> already existing as a keyword.  (Not that that's negligible.)
> ALTER CONFIGURATION is another alternative using an existing keyword
> that might be worth considering.

Yeah, I thought about something like that.  Aside from saving on
keywords, the reason I like ALTER SYSTEM or similar is that I suspect
there will be other system-wide things that we may want to let people
ALTER in the future, so I think that route might avoid an unnecessary
proliferation of top-level commands.  I am not, however, deadly
attached to the idea, if someone's got a good reason for preferring
something else.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: c language functions
Next
From: Rodrigo Barboza
Date:
Subject: Re: c language functions