Re: Custom gucs visibility

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Nikhil Sontakke <nikkhils(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom gucs visibility
Date: 2013-07-02 16:12:11
Message-ID: 20130702161211.GA10978@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 02, 2013 at 11:37:13AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke <nikkhils(at)gmail(dot)com> wrote:
> >> Should we do something about this or we are ok with the current
> >> behavior? I would prefer to get to see the config parameter value
> >> if I so happen to want to see it before the load of that contrib
> >> module. Thoughts?
>
> > If we haven't loaded the .so yet, where would we get the list of
> > custom GUCs from?
>
> This has come up before. We could show the string value of the GUC,
> if it's been set in postgresql.conf, but we do not have correct
> values for any of the other columns in pg_settings; nor are we even
> sure that the module will think the value is valid once it does get
> loaded. So the consensus has been that allowing the GUC to be
> printed would be more misleading than helpful.

How about printing them with something along the lines of, "Please
load extension foobar for details" or (less informative, but possibly
easier to code) "libfoobar.so not loaded." ?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2013-07-02 16:29:40 Re: Large object + FREEZE?
Previous Message Claudio Freire 2013-07-02 16:02:01 Re: Randomisation for ensuring nlogn complexity in quicksort