Mike Rylander wrote:
> On 8/14/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > Bruce Momjian wrote:
> >
> > > Basically, the default GUC doesn't work because of:
> > >
> > > error prone
> > > if super-user only, non-super-user doesn't work on restore
> > > if non-super-user, can cause mismatch (perhaps this is the best
> > > option), and restore still a problem (no storage of config in
> > > indexes or tables)
> >
> > I haven't really seen anyone else arguing about this. I wonder whether
> > you are being overly zealous about it.
>
> I hate to just pile on Bruce, but as a production user I tend to
> agree... let me shoot myself in the foot. :)
>
> --miker
Sure, we can document hazards, but the larger problem is related to the
fact that the default controls what gets stored in the database. This is
a similar problem to when we had an autocommit GUC which caused
problems.
Technically, this is like how the server encoding affects what is stored
in the database. If we allowed users to change the server encoding in a
database that already had data in it, there would be no way to identify
which data was using the old encoding and which was using the new one.
Now, the application might be able to identify them just fine, but a
database restore would be unable to recreate the data the same way.
If we want to keep the default GUC we would have to allow non-super-user
changes so we can use it in pg_dump for restore, but even then if the
default is different there is going to be a mix of old/new after the
restore because table changes after the restore is going to use the new
default config.
Perhaps the best we could do is to tell people who change the default GUC
that they are on their own in restoring the database, or they have to be
very carful like with triggers to assign the configuration properly. I
can imagine how complex that part of the documentation will be, but it
is doable.
The other point is that we should have a good idea of the API because
if it gets into 8.3 it will be harder to change.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
