Peter Eisentraut <peter_e@gmx.net> writes:
> brook@biology.nmsu.edu writes:
>> As far as the general utility of it goes, I claim that it could be
>> quite valuable. I am thinking of complex new datatypes (that might be
>> dynamically loaded) that could benefit from having some run-time
>> variables specify some aspect of their behavior. Currently, we have
>> variables controlling the I/O of dates and times, for example.
>> Something analogous would potentially be useful for other datatypes.
> Consider it an encouragement to have your data types not duplicate any of
> the various insane properties that date/time types have, imposed by the
> real world.
Unfortunately, real-world requirements impinge upon most things ;-)
I'm somewhat persuaded by Brook's argument.
The original discussion didn't really reject the idea of allowing
addition of new GUC variables; the concerns were about how and when
to do that. We didn't like Joe's suggestion of registering any random
name that happens to appear in postgresql.conf (no error checking, and
besides how would you deduce the type and other properties?). However,
it seems like you *would* like added-on names to be settable from
postgresql.conf, so just allowing dynamically loaded modules to add them
when first invoked by a backend would be very limiting.
Now that we have the notion of postmaster-preloaded dynamic libraries,
I was thinking maybe we could let those libraries define new GUC variables.
Right now, preload_libraries doesn't get processed until after we've
scanned guc.c, but maybe that could be rethought. Could we preload a
library at the instant we see the preload_library setting in guc.c,
allowing it to define GUC vars that will be recognized later in the
file?
There are probably other ways we could attack it, too, but that was the
first thing that came to mind.
regards, tom lane