Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] plpgsql, return can contains any expression

From: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org, neilc(at)samurai(dot)com
Subject: Re: [HACKERS] plpgsql, return can contains any expression
Date: 2006-09-15 21:17:48
Message-ID: BAY114-F21BB578F2FA3B0B772FFA2F92E0@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches

>
>"Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)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/


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-09-15 21:20:56
Subject: Re: Release notes
Previous:From: Gregory StarkDate: 2006-09-15 21:06:16
Subject: Re: Optimize ORDER BY ... LIMIT

pgsql-patches by date

Next:From: Tom LaneDate: 2006-09-15 21:23:59
Subject: Re: Include file in regress.c
Previous:From: Magnus HaganderDate: 2006-09-15 20:57:34
Subject: Update to msvc build sys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group