| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Nikhil Sontakke <nikkhils(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Custom gucs visibility |
| Date: | 2013-07-02 15:37:13 |
| Message-ID: | 6108.1372779433@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-07-02 15:37:37 | Re: MVCC catalog access |
| Previous Message | Peter Geoghegan | 2013-07-02 15:36:38 | Re: Randomisation for ensuring nlogn complexity in quicksort |