Re: Should we get rid of custom_variable_classes altogether?

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Or do you want to open SET typo.wrogn TO 'foobar' to just work silently?
>
> Well, right at the moment it *does* work silently, as long as the prefix
> is one you listed in custom_variable_classes. I don't think we want to
> take that away, and in particular I don't want to assume that every
> variable will be declared in advance. It's a fairly safe bet that there
> are some apps out there that would be broken by such a requirement.

Fair enough I suppose. But I think we could break that requirement if
we offer a good enough way out.

> At the same time, I'd kind of like to see a facility for declaring such
> variables, if only so you could define them to be bool/int/real not just
> strings. But this is getting far afield from the immediate proposal,
> and no I'm not volunteering to do it.

I think we are able to handle that part when dealing with C extension's
GUCs, because those are declared in the .so. We only need to add them
to the control file, the only road block here used to be c_v_c.

What I have in mind for extensions now that c_v_c is out would be to be
able to declare any GUC in the control file, with default values, and
without forcing extension to handle the GUC in its .so — I don't think
we have to change the code beside removing the c_v_c checks here.

In the general case, how far exposing DefineCustomBoolVariable and all
at the SQL level would get us? Then you could allow the session to add
any new GUC by calling that first, SET would bail out if given unknown
variable.

Yes, it would still break some existing applications, but I think it'd
be worth it (and an easy fix too, as I guess most shared variables are
going to be used in PL code, and if you ask me this code should now be
an extension and the control file would then declare the GUCs).

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support