Re: proposal: custom variables management

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