Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
От | Boszormenyi Zoltan |
---|---|
Тема | Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Дата | |
Msg-id | 52015414.9060900@cybertec.at обсуждение исходный текст |
Ответ на | 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>) |
Список | 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@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. 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/
В списке pgsql-hackers по дате отправления: