Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings - Mailing list pgsql-hackers

From Stefan Seifert
Subject Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings
Date
Msg-id 1674217.XTI7CnVsO0@sphinx
Whole thread Raw
In response to Re: Re: [DOCS] Docs incorrectly claiming equivalence between show and pg_settings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-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



pgsql-hackers by date:

Previous
From: Dmitry Voronin
Date:
Subject: Re: New functions for sslinfo extension
Next
From: Воронин Дмитрий
Date:
Subject: New functions for sslinfo extension