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 (st...@mit.edu) wrote: > >>On Fri, Aug 2, 2013 at 4:05 PM, Stephen Frost <sfr...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
