Re: Merging postgresql.conf and postgresql.auto.conf

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Merging postgresql.conf and postgresql.auto.conf
Дата
Msg-id CA+TgmoaHnWD+Gu50SAaRDDwFguoTCz6c39nrJzr+HFjagUB4PQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Merging postgresql.conf and postgresql.auto.conf  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Merging postgresql.conf and postgresql.auto.conf  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: proposal: disallow operator "=>" and use it for named parameters
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Reducing buildfarm disk usage: remove temp installs when done