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
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 |