Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date: 2013-07-29 05:47:54
Message-ID: m24nbd9at1.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> One of the biggest current complaints about recovery.conf from
>> Debian/Ubuntu users is the fact that it lives in $PGDATA. Won't we just
>> get the same thing here?

I don't think so, see below.

> I don't think that's the same case, but ... why exactly don't they like
> recovery.conf, and can you show that the location of the file has
> anything to do with the underlying complaint? Personally I bet it's
> more about the confusion between configuration and triggering functions.
> Until we can get those things separated, using recovery.conf to argue
> about file locations will result in nothing but confusion and bad
> design.

I think it's all about having a user-edited configuration file somewhere
else than /etc, and that keeping the triggering functions separated from
the setup itself would be a good thing to have.

I bet that if some facts and links are necessary they will appear soon,
now is not a right time for me to be searching for those facts…

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KONDO Mitsumasa 2013-07-29 06:04:56 Re: Design proposal: fsync absorb linear slider
Previous Message Andrew Gierth 2013-07-29 05:42:03 Re: Review: UNNEST (and other functions) WITH ORDINALITY