On Mon, Oct 3, 2011 at 00:05, Tom Lane <tgl@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