public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Tom Lane <[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 14:35:33 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On Sat, Apr 19, 2014 at 01:38:16PM -0400, Tom Lane wrote:
> 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.
Oh, I had forgotten these were placeholders that get replaced later.
> 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.
OK, let's wait to see if anyone else complains --- if so, we can
document the SHOW ALL and pg_settings behavior in the placeholders
section.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
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