Re: proposal: plpgsql - iteration over fields of rec or row variable

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 20:13:00
Message-ID: AANLkTimXR4PcZBZ9sS-QPn6YiCPwM=9osF4wjUJhCWtG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-11-08 20:14:20 Re: UNION ALL has higher cost than inheritance
Previous Message Merlin Moncure 2010-11-08 20:09:39 Re: proposal: plpgsql - iteration over fields of rec or row variable