Re: Parsing config files in a directory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, 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-29 15:38:07
Message-ID: 6172.1256830687@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Another option would be to introduce a section syntax, something like
> what M$ does. We could define a line that contains just [foo] to mean
> "define foo as a custom variable class and automatically put all the
> rest of the settings in this section into that namespace".

That seems like a pretty darn bad idea, unless we munge the parser to
terminate the section when exiting a particular include file. Otherwise
files that don't set custom_variable_class will have surprising
interactions with those that do. I don't see any particularly great
benefit in allowing people to omit the prefix anyway --- what if you
want to set some custom and some standard variables? With the above
definition you can't do that.

The fact that custom_variable_classes interacts with other declarations
around it is already an ugly misfeature of the design. Let us please
not add more such interactions.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-29 15:42:45 Re: Parsing config files in a directory
Previous Message Andrew Dunstan 2009-10-29 15:34:38 Re: Parsing config files in a directory