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.unknown.charter.com Whole thread Raw |
In response to | Re: Parsing config files in a directory (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Parsing config files in a directory
|
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: