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

2013-08-05 16:01 keltezéssel, Stephen Frost írta:
> * Greg Stark (stark@mit.edu) wrote:
>> On Fri, Aug 2, 2013 at 4:05 PM, Stephen Frost <sfrost@snowman.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.

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

>
>     Thanks,
>
>         Stephen


-- 
----------------------------------
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/