Re: Parsing config files in a directory

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-25 22:15:31
Message-ID: 603c8f070910251515n125c6964ofb59a736b601fe90@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 25, 2009 at 6:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I don't really understand this.  What usage habits do we need to
>> change?
>
> The assumption that it's okay to document what you've done with
> something like
>
>        # work_mem = '1GB'
>        # changed to give saner behavior 10/25/08
>        work_mem = '10MB'
>
>> The problem is that people expect that the setting for some
>> GUC is going to be near the comment block that describes that GUC.
>
> Or more generally, that the comments they've put next to a setting
> are going to stay next to it.  Once again: this isn't about the
> instructions.

I just don't buy it. With the instructions in the file, a program
that rewrites the file will fail miserably on every installation out
there (or will be full of logic that tries, futilely, to parse the
comments). With the instructions out of the file, a program that
rewrites the file will work just fine on all installations except
those that have chosen to do the thing you describe above. And we can
tell people "don't do that any more, because it'll mess up the
automated tools".

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Devrim GÜNDÜZ 2009-10-25 22:17:17 License clarification: BSD vs MIT
Previous Message Tom Lane 2009-10-25 22:06:30 Re: Parsing config files in a directory