Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, David Johnston <polobo(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date: 2013-08-06 19:52:52
Message-ID: 52015414.9060900@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013-08-06 19:41 keltezéssel, Bruce Momjian írta:
> On Tue, Aug 6, 2013 at 06:34:35PM +0200, Boszormenyi Zoltan wrote:
>> 2013-08-05 16:01 keltezéssel, Stephen Frost írta:
>>> * Greg Stark (stark(at)mit(dot)edu) wrote:
>>>> On Fri, Aug 2, 2013 at 4:05 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>>>>>> I'm not even clear we do want this in /etc since none of our GUC
>>>>>> options are repeatable things like Apache virtual servers. It actually
>>>>>> makes *more* sense for pg_hba than it does for gucs. I think we can
>>>>>> assume that in the future we'll have something like it however.
>>>>> I tend to agree with this also, though I can imagine wanting to separate
>>>>> things in a conf.d directory ala exim's conf.d directories, to allow
>>>>> tools like puppet to manage certain things environment-wide (perhaps
>>>>> krb_server_keyfile) while other configuration options are managed
>>>>> locally.
>>>> Extensions are actually a pretty good argument for why conf.d in /etc
>>>> (or wherever the non-auto-config is) is pretty important useful.
>>>> That's the kind of thing conf.d directories are meant for. A user can
>>>> install a package containing an extension and the extension would
>>>> automatically drop in the config entries needed in that directory.
>>> Agreed, though I think there should be a difference between "shared
>>> library load" being added-to for extensions, and "random
>>> extension-specific GUC"..
>> Now that you mention "shared library load", it may be a good idea
>> to add an "append-to-this-GUC" flag instead of overwriting the
>> previous value. Two GUCs may make use of it: shared_preload_libraries
>> and local_preload_libraries. It would make packagers' of extensions
>> and DBA's lives easier.
> 'search_path' might also use it, though we might need append and
> prepend.

Indeed. Although I was thinking along the lines of the GUC parser, so:

shared_preload_library += 'some_new_lib'

would append to the old value.

Maybe "<+=" is intuitive enough for prepending, or someone may
come up with a better idea.

But the extra flag would still be needed to indicate the GUC is a list,
so these new operators are usable on them and not on regular GUCs.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-08-06 20:42:12 Re: DATE type output does not follow datestyle parameter
Previous Message Claudio Freire 2013-08-06 18:55:46 Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters