On Sun, Jul 17, 2011 at 12:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Jul 16, 2011 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> Is there any way that we could get *rid* of custom_variable_classes?
>
>>> Well, we could just drop it and say you can set any dotted-name GUC
>>> you feel like.
>
>> ...and the fact that we've made them set an extra GUC to shoot
>> themselves in the foot hardly seems like an improvement. I was more
>> thinking along the lines of having loadable modules register custom
>> variable classes at load time, through some sort of C API provided for
>> that purpose, rather than having the user declare a list that may or
>> may not match what the .so files really care about.
>
> Well, we *do* have a C API for that, of a sort. The problem is, what do
> you do in processes that have not loaded the relevant extension? (And
> no, I don't like the answer of "let's force the postmaster to load every
> extension we want to set any parameters for".)
>
> I agree custom_variable_classes is conceptually messy, but it's a
> reasonably lightweight compromise that gives some error checking without
> requiring a lot of possibly-irrelevant extensions to be loaded into
> every postgres process.
Hmm. Maybe what we need is a mechanism that allows the configuration
to be associated a loadable module, and whenever that module is
loaded, we also load the associated configuration settings. This is
probably terribly syntax, but something like:
ALTER LOAD 'plpgsql' SET plpgsql.variable_conflict = 'whatever';
AFAICS, that would remove the need to set variables in postgresql.conf
that can't be validated, and so we could just disallow it.
OTOH, maybe that's more trouble than can be justified by the size of
the problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company