Re: proposal: custom variables management

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: proposal: custom variables management
Date: 2007-03-05 23:54:36
Message-ID: 45ECADBC.7080509@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?).

I think the use I had in mind for properly working custom variables fits
more squarely with common GUC usage, though.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Kirkwood 2007-03-06 00:06:46 Re: Bug: Buffer cache is not scan resistant
Previous Message Florian G. Pflug 2007-03-05 23:54:15 Re: Bug: Buffer cache is not scan resistant