Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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
