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.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
