"Magnus Hagander" <magnus@hagander.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.
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.
>> 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.
>> 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.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!
