On Sat, Jul 16, 2011 at 10:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jul 15, 2011 at 8:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 2. Tentatively apply the new custom_variable_classes setting if any. > >> Is there any way that we could get *rid* of custom_variable_classes? >> The idea of using a GUC to define the set of valid GUCs seems >> intrinsically problematic. > > Well, we could just drop it and say you can set any dotted-name GUC > you feel like. The only reason to have it is to have some modicum of > error checking ... but I'm not sure why we should bother if there's no > checking on the second half of the name. Not sure if that's going too > far in the laissez-faire direction, though. I can definitely imagine > people complaining "I set plpqsql.variable_conflict in postgresql.conf > and it didn't do anything, how come?"
I'm not sure that's really making anything any better. Maybe I'm misunderstanding, but if that's going to be a problem, then presumably this will create the same problem: custom_variable_classes='plpgsql' plpgsql.variable_conflict='on' ...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. -- 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
