RE: Enhancement Idea - Expose the active value of a parameter in pg_settings

From: Greg Clough <greg(dot)clough(at)ipreo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(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 16:14:46
Message-ID: MWHPR03MB31338BFA390B5CB30F37FE9AF7690@MWHPR03MB3133.namprd03.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> On Fri, May 25, 2018 at 10:11 AM, Andrew Dunstan
>> <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>>> He's proposing an extra column to show the actual value used, so
>>> distinguishing them should be a problem.
>
>> For most settings, that column would just be a duplicate. For a
>> handful, it would pull in the value of some other GUC. If somebody
>> finds that useful, cool, they can write a view that does it and
>> install it on their own cluster. I don't think that it makes a lot of
>> sense to put it in core, though. My guess would be that more people
>> would be annoyed or confused by the extra column than would be pleased
>> or enlightened by it. I could of course be wrong.
>
> Yeah, that's pretty much my evaluation --- given the tiny number of
> GUCs that have behaviors like this, an extra column seems like it
> would mostly be confusing. Plus, pg_settings is too darn wide already.
>
> 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.
>
> regards, tom lane

Many thanks for the quick consideration, even if it's ultimately a rejection. Figuring out some SQL that will work across all platforms, versions, and compile-time options will be "fun", but I'm up for a challenge.

It came about because I was scraping the entire cluster with "pgmetrics", and I was trying to reduce all "size" numeric settings down to bytes for them. I figured it would be nice if PostgreSQL could expose the data it's already got rather than forcing all external applications that want that data to do the same thing.

I'll deal with it externally, but I hope it was a reasonable proposal and not completely off-the-wall.

Regards,
Greg Clough.

********* Confidential Disclaimer *********

This e-mail message and any attachments are confidential. Dissemination, distribution or copying of this e-mail or any attachments by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please notify Ipreo immediately by replying to this e-mail, and destroy all copies of this e-mail and any attachments. If you have received this e-mail as part of a marketing communication and you would like to unsubscribe from future marketing communications, please review our privacy policy<http://info.ipreo.com/Ipreo-Private-Policy.html> for more information.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-05-25 16:16:41 We still claim "cannot begin/end transactions in PL/pgSQL"
Previous Message Tom Lane 2018-05-25 16:10:28 Re: rule-related crash in v11