Re: Parsing config files in a directory - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: Parsing config files in a directory
Date
Msg-id 1256832832.10954.30.camel@jd-desktop.iso-8859-1.charter.com
Whole thread Raw
In response to Re: Parsing config files in a directory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2009-10-29 at 11:42 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > The whole config file is a joke. We'd never do it the way we do if we 
> > were designing it from scratch,
> 
> Why not, pray tell?  We did design it from scratch, once upon a time,
> and I don't see that the design is so obviously broken that we'd not
> do the same thing if starting over.

Because, there is no right answer. There is not a defined standard to
attach to. The requirements all over the place and in this case there
are a large number of contributors that actually have an opinion (unlike
say the Hot Standby implementation).

> 
> > but we seem to be incapable of biting 
> > the bullet and replacing it with something sane, which is why I have 
> > ignored most of the current debate.
> 
> I guess we'll just go without the benefit of your superior intelligence
> then.

I think the point is, this discussion has happened many times. People
get kind of tired of burning cycles on the same thing over and over.

I personally don't have any problem with the existing postgresql.conf
except for the following:

1. I should be able to edit it from PostgreSQL via a query (assuming
super user privs or some such thing)

In fact I would be perfectly happy to NEVER open an editor again to edit
the postgresql.conf and just have a revision system in conjunction with
a SET LOCAL|GLOBAL command. Where local would be for the session and
GLOBAL would be permanent.

Then again, I don't really care that I have to open an editor either. I
also understand that a SET LOCAL|GLOBAL is likely to wreak havoc on an
include implementation. Of course a SET LOCAL|GLOBAL implementation
eliminates the need for an include implementation. Queue up the
pitchforks now.

2. The file contains a bunch of information that shouldn't be there. We
should have the bare minimum required for PostgreSQL to start. 

As far as this on-going postgres vs postgresql debate. There are some
already pretty well defined industry (if not specific body) standards
for configuration files.

The ones I run into the most are:

XML : Pretty much anything written in Java is going to use this 

Config : This is what you see in a lot of Perl or Python installs where
you have something like this:

[CONNECTIONS]
listen_addresses = 

[PERFORMANCE]
checkpoint_segments = 

etc...

In regards to parsing files in a directory. It makes sense. Why the
implementation is so difficult is beyond me. Can't we just look at
Apache and say, "Gee, it may not be perfect but it does everything we
need, let's use their implementation."?

Sincerely,

Joshua D. Drake


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Syntax for partitioning
Next
From: Jeff Davis
Date:
Subject: Re: Syntax for partitioning