Re: SHOW ALL doesn't actually SHOW ALL

Folks,

I've noticed that neither SHOW ALL nor SELECT ... FROM pg_settings
shows the value of custom GUCs, even though SHOW will do so for any
given one. For example:

SHOW plperl.use_strict;
plperl.use_strict
-------------------
true
(1 row)

SELECT * FROM pg_settings WHERE "name" = 'plperl.use_strict';
name | setting | unit | category | short_desc | extra_desc | context | vartype | source | min_val | max_val
------+---------+------+----------+------------+------------+---------+---------+--------+---------+---------
(0 rows)

Is this a bug?

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

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

David Fetter <david(at)fetter(dot)org> writes:
> I've noticed that neither SHOW ALL nor SELECT ... FROM pg_settings
> shows the value of custom GUCs, even though SHOW will do so for any
> given one.

Yeah, that's intentional, because what the code is designed to do is
allow GUC values for a user-written module to be specified before the
user-written module has been loaded. It's expecting the user-written
code to come along and issue a DefineCustomXXXVariable call so that
it will know how (or whether) to display the variable.

This ties back into previous discussions about how using this facility
for random user-set values is an abuse, and we ought to instead provide
some way of explicitly declaring user variables.

regards, tom lane

On Wed, Aug 20, 2008 at 01:56:50PM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > I've noticed that neither SHOW ALL nor SELECT ... FROM pg_settings
> > shows the value of custom GUCs, even though SHOW will do so for
> > any given one.
>
> Yeah, that's intentional, because what the code is designed to do is
> allow GUC values for a user-written module to be specified before
> the user-written module has been loaded. It's expecting the
> user-written code to come along and issue a DefineCustomXXXVariable
> call so that it will know how (or whether) to display the variable.

I'm not sure I understand why that's the right thing. I stumbled
across it while trying to improve some SQL-only checks in DBI-Link,
and since SHOW doesn't quite act like SELECT, it's causing some
trouble.

> This ties back into previous discussions about how using this
> facility for random user-set values is an abuse, and we ought to
> instead provide some way of explicitly declaring user variables.

How about seeing what all of them are via SELECT? I guess I'm missing
why pg_show_all_settings(), the function underlying the pg_settings
view, is actually doing
pg_show_settings_except_the_ones_you_actually_set() :P

Cheers,
David.

>
> regards, tom lane

--
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

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