On Mon, Mar 05, 2007 at 06:54:36PM -0500, Andrew Dunstan wrote: > Tom Lane wrote: > >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.) > > 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 <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly