On Sat, Jul 16, 2011 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jul 15, 2011 at 8:02 PM, Tom Lane <tgl@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
