On Sat, 24 Oct 2009, Robert Haas wrote:
> But the only way to solve the problem of machine-parsing the config file
> is to remove the instructions (which can only EVER be parsed by human
> beings) and put them somewhere else.
Ah, back to this again already. Your suggestion presumes there is someone
who can successfully force a decision to deprecate the existing format.
There is no such person, and thinking you have to win that battle is one
of the many traps one can fall into here and never escape from.
The roadmap here looks something like this:
1) Support a standard for include directories
2) Update tools to use them rather than ever modifying the primary
postgresql.conf
3) Once one of those matures, bundle a standard tool with the database
that does most of what people want for initial configuration. That only
has to worry about writing to the new include directory format rather than
trying to parse existing postgresql.conf files and write them back out
again at all.
4) Once the tool has proven itself, and people have become more
comfortable with using the newer config format, allow the option of
generating a shorter example file rather than the current large one.
5) Completely deprecate the giant config file *only* if the new approach
becomes so wildly successful that fans of editing the giant file admit
defeat at the hands of the new approach. This is completely optional and
possibly not ever possible.
If we get bogged down presuming (5) is the first useful step here, which
seems to be what you're suggesting, no progress will ever get made here.
> To reiterate, I have no problem with the proposal (I have not examined
> the code), but I respectfully submit that it's not solving the problem
> you think it's solving.
As the message introducing it says, the goal this aims at is making life
easier for tool builders. I think you're extrapolating beyond its
intended scope in your evaluation of what problem it's aiming to solve.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD