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

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Greg Stark <stark@mit.edu>
Cc: 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-05T14:01:46Z
Lists: pgsql-hackers
* 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"..

	Thanks,

		Stephen