From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: plpgsql - iteration over fields of rec or row variable |
Date: | 2010-11-08 21:21:17 |
Message-ID: | AANLkTin_R4iZ_EJF2n0bk9S--Sjgbg8dh3=c2ZMVhm6H@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 8, 2010 at 3:21 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2010/11/8 Merlin Moncure <mmoncure(at)gmail(dot)com>:
>> On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>> Most cases of this feature are for dealing with new/old from trigger
>>>> function right? Why not build a complete new plan for each specific
>>>> trigger that invokes the function, along with some magic values like
>>>> (TG_FIELDNAMES -> text[]) that could be iterated for the mojo. Not
>>>> sure how you get direct type assignment to variable but it could
>>>> probably be worked out.
>>>
>>> if I understand well - it's not too far to my idea - just you create
>>> instance on function level? It is possible too. As disadvantages I
>>> see:
>>> a) you need some special syntax too
>>> b) there is overhead with multiple function call
>>> c) you have to manage some space for temporary values
>>
>> yes. If you need to deal with plan instance it should be at function
>> level IMO. There are other cases for this, search_path for example.
>> What overhead?
>
> you call a trigger body more times then once. The call of plpgsql
> isn't cheep. Main problem is missing a some working memory. Task:
> ensure so sum of fields must be less than some constant?
>
> What is solution in your design?
nothing specific. My main interest is in the plan management portion
(only because of side interest in search_path which is complete mess
at present). if plpgsql_compile knows that it is trigger function and
which table fired the trigger, you can generate specific hash key, and
take advantage of new/old being well defined inside function
execution. This seems less fiddly than trying to deal with plan
mechanics inside the function. My knowledge stops there -- I don't
have a real good understanding of how plpgsql works internally. If
this idea passes smell test maybe it merits more research.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-11-08 21:28:36 | Re: W3C Specs: Web SQL |
Previous Message | Andrew Dunstan | 2010-11-08 21:17:50 | Re: W3C Specs: Web SQL |