From: Stefan Seifert <nine@detonation.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and
 pg_settings
Date: Sat, 19 Apr 2014 21:08:30 +0200
Message-ID: <1674217.XTI7CnVsO0@sphinx>
User-Agent: KMail/4.12.4 (Linux/3.14.0-2.ge60ddcf-desktop+; KDE/4.12.4;
 x86_64;
 ; )
In-Reply-To: <9741.1397929096@sss.pgh.pa.us>
References: <6963016.0JgteVRq9S@sunshine.detonation.org>
 <20140419171257.GA3653@momjian.us> <9741.1397929096@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On Saturday 19 April 2014 13:38:16 Tom Lane wrote:

> >         3  document this restriction
> 
> 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.

http://www.postgresql.org/docs/devel/static/runtime-config-custom.html
states: "Because custom options may need to be set in processes that have not 
loaded the relevant extension module, PostgreSQL will accept a setting for any 
two-part parameter name."
So I'd say the possibility of using SET this way is somewha documented. That's 
at least how I actually got the idea of doing that.

Maybe it can help if I describe our use case: we have some plperlu stored 
procedures and triggers that use them that replicate specific data from our 
internal management application's database to the system on our webserver. 
When running the application's test suite though we obviously don't want that 
and instead want it to replicate to another local database, so we can test the 
triggers as well. We use a custom option set by our test suite to communicate 
the required change in replication target to the stored procedure. As a nice 
side effect we can use the same mechanism to prevent a test sandbox version of 
the application from trying to replicate to the webserver.

So far this works quite well except for the SHOW command throwing an exception 
when we request an unknown configuration parameter complicating our stored 
procedure a little. It would be more comfortable if we could query pg_settings 
and just get an empty result if the configuration parameter is not set.

Regards,
Stefan


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