Re: proposal: custom variables management

On Mon, Mar 05, 2007 at 06:54:36PM -0500, Andrew Dunstan wrote:
> 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?).

YAML could work, but JSON <http://www.json.org/> is a lot less
sensitive to what should be trivial matters of whitespace.

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate