Re: Permanent settings

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Permanent settings
Date: 2008-02-19 20:49:07
Message-ID: 1203454147.5837.2.camel@mha-laptop.clients.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Tue, 2008-02-19 at 19:38 +0000, Gregory Stark wrote:
> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>
> > On Tue, Feb 19, 2008 at 04:58:21PM +0000, Gregory Stark wrote:
> >
> >> The include file method is workable but isn't perfect. What happens if a user
> >> connects with pgadmin and changes a parameter but that parameter is overridden
> >> by a variable in the config file?
> >
> > Um, if you put the include statement at the bottom, isn't that the one that
> > will override?
>
> I was picturing putting it on top on the general principle that manual changes
> should override automatic ones. I see I'm in the minority though.

Oh.

> It doesn't really matter though, this is all in the manually edited file --
> the admin can always move it around or add other configuration settings below
> it.

Yeah - or take it away completely if needed.

> >> The alternative is to have two files and read them both. Then if you change a
> >> variable which is overridden by the other source you can warn that the change
> >> is ineffective.
> >
> > Ok, now I don't follow. If we use an include, we do have two files, and we
> > read them both, no?
>
> Not from the point of view of the guc processing. It's all one source. Even if
> it remembered which file various settings came from it's not going to remember
> what order they arrived or what might hypothetically override a new setting.
>
> I was describing have two independent files read separately and kept track of
> separately. That would hard code one having preference over the other and mean
> that pgadmin could look at the guc source to see if there's a command-line
> variable, environment variable, or popstgresql.conf setting which overrides
> the postgresql.auto (or whatever) settings.

Oh, ok. That does seem a bit more complicated than needed, though.

> >> I think on balance the include file method is so much simpler that I prefer it.
> >
> > Yeah, that is one very clear argument for that method.
>
> Still my feeling. We can put comments in the default config warning about the
> consequences to pgadmin of overriding variables after the include.

Yeah.

Another thing I thought about - would people prefer a function or a
parameter to the SET statement. Since I would imagine they're more or
less only to be used from frontend programs like pgadmin, it could just
as well be a function...

//Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2008-02-19 21:21:46 Re: 8.3 / 8.2.6 restore comparison
Previous Message Gregory Stark 2008-02-19 19:38:10 Re: Permanent settings