Re: proposal: custom variables management

On Mon, Mar 05, 2007 at 06:54:36PM -0500, Andrew Dunstan wrote:
> Tom Lane wrote:
> >Andrew Dunstan <andrew(at)dunslane(dot)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(at)fetter(dot)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