public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Stefan Seifert <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings
Date: Sat, 19 Apr 2014 13:38:16 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

Bruce Momjian <[email protected]> writes:
> However, in the case of custom variables, you are right that pg_settings
> doesn't show custom variables.

That is entirely intentional: the reason we do not show placeholder
variables in pg_settings is that we have no accurate information about
them, and so everything pg_settings might show would be fabricated,
and probably wrong, information.

Once the placeholder has been replaced by a proper declaration of the
GUC variable, it will be shown (with correct info), unless of course
the "proper declaration" includes GUC_NO_SHOW_ALL.

What this gets back to is that manually created "custom variables" are an
abuse of a loophole that was only meant to allow postgresql.conf to set
a parameter belonging to an extension module that hasn't been loaded yet.

If we want to actually support such variables, there should be a way to
properly declare one, including giving its type and other properties
... and ideally we'd not let you set one without having declared it,
though it's not quite clear how to enforce that without breaking the
parameter-placeholder case.

> We can do a few things:

>         1  show custom variables in SHOW ALL and pg_settings
>         2  show custom and other non-SHOW-ALL variables in pg_settings
>         3  document this restriction

or (4) fix the lack of a declaration capability.  But both (1) and (2)
are horrid ideas.  There are good reasons for having invented
GUC_NO_SHOW_ALL, and just trashing it is not the answer.

As for (3), I might be wrong, but I don't think the documentation mentions
the possibility of abusing SET this way at all.  Restrictions in
undocumented quasi-features are likewise undocumented.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox