On 21/02/2008, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Wed, 20 Feb 2008 23:02:34 -0500 > Aidan Van Dyk <[EMAIL PROTECTED]> wrote: > > > * Joshua D. Drake <[EMAIL PROTECTED]> [080220 21:15]: > > > > > The one thing this does is make the postgresql.conf basically a > > > placeholder. It is not definitive anymore, in the sense that > > > settings will be overwritten on restart. That really isn't that > > > uncommon anyway in other applications. > > > > Man, I'ld screem *bloody murder* if the config file we just finished, > > after spending days (or weeks) of careful analisys and implementation > > discussion was "overwritten" by postmaster "automatically" on server > > startup... > > > And I of course would respond, read the docs :P > > > > > > But part of that might just be user education... I personally just > > can't imagine that education could be enough to let *all* users know > > that as of version S, postgresql.conf is blatantly ignored, no, more > > exactly *purposely overwritten* with the "old" settings... > > > We could also make it optional. > > Silly point postgresql.conf has a bunch of settings that are needed by the server before it can actually read the database, Sure move out settings that are not needed early in startup but your going to get problems with others.
I quite like the function based method its flexible. Allowing pg_settings to be update able does not seam to be a bad idea but then you could do that with triggers and rules that called the functions surly? set should be for temporary transaction and session based variables, not for change permanent things thats what the SQL constructs insert, update, alter, create, delete, drop etc are for. Regards Peter
