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
