Re: Merging postgresql.conf and postgresql.auto.conf - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Merging postgresql.conf and postgresql.auto.conf
Date
Msg-id CA+TgmoaHnWD+Gu50SAaRDDwFguoTCz6c39nrJzr+HFjagUB4PQ@mail.gmail.com
Whole thread Raw
In response to Re: Merging postgresql.conf and postgresql.auto.conf  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Merging postgresql.conf and postgresql.auto.conf
List pgsql-hackers
On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> So are you telling that whenever we read, save the settings
> to some catalog (probably a new one)?

Which process are you imagining would do this?  Certainly not the postmaster.

Independently of that, it sounds like solving the problem from the
wrong end.  I think the idea of ALTER SYSTEM .. SET ought to be that
you should EITHER edit postgresql.conf for all your configuration
changes, OR you should use ALTER SYSTEM .. SET for all of your
changes.  If you mix-and-match, well, that's certainly allowed and it
will work and everything, but you - as a human being - might get
confused.  I am doubtful that any technological measures we take can
ever eliminate that confusion, because it doesn't result from some
defect of the system design, but rather from the fact that splitting
up your settings between multiple locations is inherently confusing,
especially if some settings are present in multiple locations with one
value overriding the others.

Imagine that you went out and bought a second wallet or purse.  Then
you take half of the stuff that is in your original one and put it in
the new one.  Then you order duplicates of 20% of the items and put
the copies in the wallet or purse that doesn't already contain a copy
of that item.  I predict that if you do this, you will sometimes get
confused about which one contains any particular item that you're
looking for.  But this is not anyone's fault except yours, and the
solution is simple: keep everything in one place.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: proposal: disallow operator "=>" and use it for named parameters
Next
From: Andrew Dunstan
Date:
Subject: Re: Reducing buildfarm disk usage: remove temp installs when done