On Mon, Oct 3, 2011 at 00:05, Tom Lane <t...@sss.pgh.pa.us> wrote: > > So at this point I'd vote for just dropping it and always allowing > custom (that is, qualified) GUC names to be set, whether the prefix > corresponds to any loaded module or not. > > Comments, other proposals?
While working on E.164 telephone numbers datatype contrib module (https://github.com/commandprompt/e164/commits/guc) I've stumbled across this problem: how do I add regression tests involving the module-defined GUC option? Trying to hack postgresql.conf to include e164 in the custom_variable_classes then send it a HUP doesn't seem to be an option. But it seems that you cannot (re)set it otherwise. See: $ psql -d contrib_regression psql (9.1.0) Type "help" for help. contrib_regression=# SET e164.area_codes_format=''; ERROR: unrecognized configuration parameter "e164.area_codes_format" contrib_regression=# SET custom_variable_classes='e164'; ERROR: parameter "custom_variable_classes" cannot be changed now I wonder how/if other contrib modules ever do regression tests on their GUC options? At this rate, removing the custom_variable_classes option altogether is pretty much going to solve my problem. -- Regards, Alex -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
