From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parsing config files in a directory |
Date: | 2009-10-26 14:19:07 |
Message-ID: | 28179.1256566747@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Maybe SET PERSISTENT needs to go back to postgresql.conf, add an
> automatic comment "# overridden in persistent.conf" and put a comment
> marker in front of the original line. That way the user is led to the
> actual authoritative source.
Doesn't that require the same AI-complete parsing ability we have said
we don't want to implement?
Personally I think this is just a matter of usage. If you want to use
SET PERSISTENT, don't set values manually in postgresql.conf. How is
that different from the existing rule that if you want to set values in
postgresql.conf, you'd better not set them on the postmaster command
line?
> Fortunately we now have an easy way to find out which file is each
> setting's value coming from.
Yeah --- that feature should make it easy enough to debug any conflicts.
I think we shouldn't overthink this. The separate file with a clear
warning to not edit it manually seems like a fine approach from here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-10-26 14:25:34 | Re: Parsing config files in a directory |
Previous Message | Tom Lane | 2009-10-26 14:07:53 | Re: Proposal: String key space for advisory locks |