Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If you think there's a
case for some extra functionality to be exposed, maybe you could provide
some more examples / use cases.
I think what Pavel is on about is making use of not-known-to-C-code
custom variables as all-purpose intrasession storage. However, I doubt
that insufficient granularity of protection is the first problem
standing in the way of that --- the GUC mechanism was never designed to
scale up to huge numbers of variables, and will likely start to perform
poorly if anyone tries to make extensive use of such variables. But
perhaps more to the point, I'm unconvinced that we should encourage
what's basically an abuse of the GUC mechanism. It's a handy hack at
the moment, but what if we want to change GUC later in a way that
prevents being backward compatible with this behavior? It's not
impossible for example that we might want to load the defining module
immediately when someone tries to set a custom variable, rather than
letting the value skate by unchecked. Also, while GUC is underdesigned
for the purpose of intrasession storage in some ways, it is overdesigned
in others --- the whole postgresql.conf, SIGHUP, etc mechanism is
irrelevant. So it's really a pretty poor fit. If we want to support
general-purpose intrasession variables, I think something other than GUC
ought to be providing 'em. (And, of course, it seems likely that you
could provide such functionality with a few functions in
your-favorite-PL, without any core changes at all.)
I think I agree with you :-)
But then every PL needs to invent it's own variable persistence - maybe
we should look at providing a general PL-visible persistence mechanism
which is distinct from GUC, so we don't have to keep reinventing the
wheel (YAML anyone?).
I think the use I had in mind for properly working custom variables fits
more squarely with common GUC usage, though.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
