From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Greg Clough <greg(dot)clough(at)ipreo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enhancement Idea - Expose the active value of a parameter in pg_settings |
Date: | 2018-05-25 14:32:59 |
Message-ID: | CA+Tgmobn+1XEiLCgvpmBndzv0JQQT3XvHvbit3cAaPF=VWHntA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 25, 2018 at 10:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Personally, what I'd rather do is try to get rid of GUC behaviors like
> "the effective value depends on something else". But convenience and
> backwards compatibility may be arguments against that.
Yeah. The dependency between various GUCs is something that I don't
like very much either. However, AFAICT, the limited number of GUCs
that have behaviors like this mostly all do for good reasons,
generally that there are two GUCs which people usually want set the
same way but occasionally not. Decoupling the GUCs could lead to
people accidentally shooting themselves in the foot, and as you
mention it would also break configurations that work today when users
try to upgrade. Maybe it would be worth going through that pain if we
could point to some really compelling benefit (if you do this, the
whole system can run 10% faster!) but I know of no such benefit. It
seems more like a wart than a bullet wound.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-05-25 14:33:52 | Re: Avoiding Tablespace path collision for primary and standby |
Previous Message | Chris Bandy | 2018-05-25 14:31:46 | Re: Unexpected casts while using date_trunc() |