On Sun, Jul 17, 2011 at 12:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Jul 16, 2011 at 10:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
