Re: [PATCHES] plpgsql, return can contains any expression - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [PATCHES] plpgsql, return can contains any expression
Date
Msg-id BAY114-F21BB578F2FA3B0B772FFA2F92E0@phx.gbl
Whole thread Raw
In response to Re: [PATCHES] plpgsql, return can contains any expression  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] plpgsql, return can contains any  (Bruce Momjian <bruce@momjian.us>)
Re: [PATCHES] plpgsql, return can contains any expression  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers

>
>"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> >> This patch doesn't seem to cope with cases where the supplied tuple has
> >> the wrong number of columns, and it doesn't look like it's being
>careful
> >> about dropped columns either.  Also, that's a mighty bizarre-looking
> >> choice of cache memory context in coerce_to_tuple ... but then again,
> >> why are you bothering with a cache at all for temporary arrays?
>
> > I am sorry, Tom. But I don't understand. I can check number of columns,
> > ofcourse and I'll do it. What cache for temporary arrays do you mean?
>
>I thought that making coerce_to_tuple depend on estate->err_func was
>pretty bizarre, and that there was no need for any "cache" at all for
>arrays that need only live as long as the function runs.  All you are
>saving here is a palloc/pfree cycle, which is not worth the obscurantism
>and risk of bugs (are you sure natts can never change?).

No, cache there is ugly. But I don't have idea about more efective
implementation of it :-(. First version of this patch was more clean. and
little bit slow. This cache save 10%.

>
>BTW, if you want this patch to make it into 8.2, it needs to be fixed
>and resubmitted *very* soon.

I understand, but I am not able work on it in next four days. And I need
help with it from Neil. It will be for 8.3.

Thank you
Pavel

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Optimize ORDER BY ... LIMIT
Next
From: Bruce Momjian
Date:
Subject: Re: Release notes