Date: Sat, 19 Apr 2014 14:35:33 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stefan Seifert <nine@detonation.org>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Re: [DOCS] Docs incorrectly claiming equivalence
 between show and pg_settings
Message-ID: <20140419183533.GB23526@momjian.us>
References: <6963016.0JgteVRq9S@sunshine.detonation.org>
 <20140419171039.GA23526@momjian.us>
 <20140419171257.GA3653@momjian.us> <9741.1397929096@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9741.1397929096@sss.pgh.pa.us>
User-Agent: Mutt/1.5.20 (2009-06-14)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Sat, Apr 19, 2014 at 01:38:16PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


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