public inbox for [email protected]  

help / color / mirror / Atom feed

From: Stefan Seifert <[email protected]>
To: Tom Lane <[email protected]>
Cc: Bruce Momjian <[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 21:08:30 +0200
Message-ID: <1674217.XTI7CnVsO0@sphinx> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

view thread (6+ messages)

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: <1674217.XTI7CnVsO0@sphinx>

* 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