Re: Overhauling GUCS - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Overhauling GUCS
Date
Msg-id 873anqeix0.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Overhauling GUCS  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: Overhauling GUCS  (Andreas Pflug <pgadmin@pse-consulting.de>)
List pgsql-hackers
"Andreas Pflug" <pgadmin@pse-consulting.de> writes:

> Gregory Stark wrote:
>> So all you have is our existing file except with an additional layer of
>> quoting to deal with, a useless SET keyword to annoy users, and a file that
>> you need a bison parser 
>
> Don't you think that's a little over the top, throwing bison at the simple task
> to extend postgresql.conf scanning so it accepts --, /**/ and SET?

Well you're the one who proposed generalising the simple text file format to
SET commands. 

The whole point of a machine-editable format would be to make it more
restricted and predictable, not less so. We had a proposal to do a
postgresql.conf.auto which was automatically generated included from a
free-form postgresql.conf. That file could generated in a simple format
without worrying about formatting, comments, ordering, etc.

> Text config files are NOT friendly for beginner and mediocre users. IMHO the
> current restriction on GUC changes is a major obstacle towards pgsql tuning
> tools, e.g. written as a Google SoC project. Graphic tools aren't too popular
> at pgsql-hackers, but please contemplate a little how much pgadmin may have
> contributed to the pgsql usage boost, esp. on windows.

Like it or not computers actually have to store state when you're done
entering it via the GUI. If you design around the GUI you end up with system
that can *only* be used via a GUI and spend years trying to work around that
(witness Windows which is only now with a lot of effort recovering from that
mistake).

People got all focused on comments and sed, but in fact there are a host of
reasons to want to be able to directly edit the state stored in a simple text
file. You might like to group together related options, for example, perhaps
grouping together the options that your site have to adjust between dev and
production -- and probably have instructions on how to make the transition in
a commented section.

I happen to think being presented with 200 options is less confusing than
being presented with an empty file and being told to go read the documentation
to find out whether I might want to put anything in it. The documentation is a
good reference but isn't good as a "here's what you'll want to check before
you start" guide.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: Overhauling GUCS
Next
From: Bjorn Munch
Date:
Subject: Re: orafce does NOT build with Sun Studio compiler