Re: Parsing config files in a directory

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

In response to

Responses

Browse pgsql-hackers by date

  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