Re: pgsql/ oc/src/sgml/release.sgml rc/backend/com ... - Mailing list pgsql-committers

From Joe Conway
Subject Re: pgsql/ oc/src/sgml/release.sgml rc/backend/com ...
Date
Msg-id 3D39B6FC.4040605@joeconway.com
Whole thread Raw
In response to pgsql/ oc/src/sgml/release.sgml rc/backend/com ...  (tgl@postgresql.org (Tom Lane))
Responses Re: pgsql/ oc/src/sgml/release.sgml rc/backend/com ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> Okay, so the question is what tablefunc wants to do.  I'd guess it
> wants to duplicate the set of info returned by SHOW ALL.

Yes, I think that makes sense.



> I put in GUC_NO_SHOW_ALL when I was hacking on GUC a few months ago
> to make it able to implement the last few SET variables that had
> one-of-a-kind behavior.  One of those one-of-a-kind behaviors was that
> some of them didn't show up in SHOW ALL.  I suppose this is arguably
> a bug and not really behavior we want to preserve --- although SHOW SEED
> will *never* return anything useful and so it's not clear why SHOW ALL
> should bother to show it.
>
> If NO_SHOW_ALL bothers you, feel free to put its removal up to a
> pghackers vote.  I'm not wedded to it.

It doesn't really bother me ;). I just didn't understand why it existed.

I do think that it is conceivable that we want to be able to suppress
the examination of some settings, but I would think that would apply to
SHOW just the same as SHOW ALL. It seems that anything I can SHOW should
be there when I do SHOW ALL. Maybe it should be GUC_NO_SHOW and apply to
both?

Joe


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql/ oc/src/sgml/release.sgml rc/backend/com ...
Next
From: Tom Lane
Date:
Subject: Re: pgsql/ oc/src/sgml/release.sgml rc/backend/com ...