Re: proposal: plpgsql - iteration over fields of rec or row variable - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql - iteration over fields of rec or row variable
Date
Msg-id AANLkTinOAgkW21bjhkcNFnpR0LPkuVKK_eARb8yGFbqe@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql - iteration over fields of rec or row variable  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: proposal: plpgsql - iteration over fields of rec or row variable
List pgsql-hackers
2010/11/8 Merlin Moncure <mmoncure@gmail.com>:
> On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule <pavel.stehule@gmail.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?

Pavel

>
> merlin
>


pgsql-hackers by date:

Previous
From: Dmitriy Igrishin
Date:
Subject: Re: proposal: plpgsql - iteration over fields of rec or row variable
Next
From: Tom Lane
Date:
Subject: Re: UNION ALL has higher cost than inheritance