Re: Should we get rid of custom_variable_classes altogether?

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