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