Horton

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

Bruce Momjian <bruce@momjian.us>

View thread View on postgr.es
From: Bruce Momjian <bruce@momjian.us>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Stephen Frost <sfrost@snowman.net>, Greg Stark <stark@mit.edu>, Amit Kapila <amit.kapila@huawei.com>, Andres Freund <andres@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, David Johnston <polobo@yahoo.com>, pgsql-hackers@postgresql.org
Date: 2013-08-06T17:41:48Z
Lists: pgsql-hackers 
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@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.

'search_path' might also use it, though we might need append and
prepend.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +