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

From Merlin Moncure
Subject Re: proposal: plpgsql - iteration over fields of rec or row variable
Date
Msg-id AANLkTimXR4PcZBZ9sS-QPn6YiCPwM=9osF4wjUJhCWtG@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql - iteration over fields of rec or row variable  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: plpgsql - iteration over fields of rec or row variable
List pgsql-hackers
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?

merlin


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: proposal: plpgsql - iteration over fields of rec or row variable
Next
From: Dimitri Fontaine
Date:
Subject: Re: UNION ALL has higher cost than inheritance