Re: Permanent settings

On Wed, Feb 20, 2008 at 11:53:47PM +0000, Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 
> > Andrew Dunstan <andrew@dunslane.net> writes:
> >> All this discussion seems to me to be going off into the clouds, where 
> >> every objection is met with some still more elaborate scheme. I think we 
> >> need to look at simple, incremental, and if possible backwards 
> >> compatible changes.
> >
> > +1.  Let me propose the simplest possible scheme, namely
> >
> > The SQL-exposed function knows how to find and replace the definition
> > of a variable (commented or otherwise) in the primary configuration
> > file.  It does not chase INCLUDEs.  If it doesn't find the target
> > variable anyplace in the primary file, it errors out.
> 
> I think there are a few problems with having the function edit the primary
> config file:
> 
> 1) It requires parsing and dealing with arbitrary user data. There could be
> comments on the same line, the order or white-space might be important to the
> user, etc.

That is the big one.


> 2) How would this interact with config files outside of the data directory? If
> you have multiple postgres clusters using the same config fie or if your
> config file is in read-only media (as /etc often is) or if you're a packager
> where editing user-maintained /etc files is a forbidden and an awful idea this
> all leads to problems.

If it doesn't have permissions, it fails. 


> I think it's much cleaner to have a postgresql.conf.auto file in the data
> directory which has a limited syntax. No comments, no extra white-space, and
> no includes. The user is not expected to edit it, though he can. The functions
> edit it using simple algorithms which add and remove single lines. 

Yes, that's certainly going to be the easiest implementation. And I think
that can be a good starting-point. We can always change the implementation
later as long as we have a stable API for it. But we need to start the
implementatino with something that's reasonably low-impact for others.
Incremental development is supposed to be what OSS rocks at :)


//Magnus