From: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> |
---|---|
To: | andrew(at)dunslane(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal: custom variables management |
Date: | 2007-03-06 06:38:45 |
Message-ID: | BAY20-F23DFBE091A91A53EEB2B9BF97B0@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>
>
>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 know, so GUC aren't optimal for it. Any storage of Datum values can be
better. I am thinking about using one row memory tables (similar ROW type
from plpgsql). And access via clasic SQL statements. It's need only some
game with executor and type cache. It can be cheaper than temporary tables
with same functionality.
Using:
* trusted storage for debug info
* trusted storage for state variables (vector)
* trusted storage for expensive variables
* trusted sharing values between PL
>I think the use I had in mind for properly working custom variables fits
>more squarely with common GUC usage, though.
>
I'll try implement my minimalistic version.
Regards
Pavel Stehule
_________________________________________________________________
Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com.
http://www.msn.cz/
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2007-03-06 06:44:42 | Re: proposal: custom variables management |
Previous Message | Sherry Moore | 2007-03-06 05:41:14 | NTA access on Solaris |