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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
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 14:56:58
Message-ID: 24714.1158332218@sss.pgh.pa.us (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?).

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

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: D'Arcy J.M. CainDate: 2006-09-15 14:58:53
Subject: Re: New version of money type
Previous:From: Rocco AltierDate: 2006-09-15 14:44:32
Subject: Re: [PATCHES] Linking on AIX (Was: Fix linking of OpenLDAP libraries )

pgsql-patches by date

Next:From: Albe LaurenzDate: 2006-09-15 14:59:42
Subject: Dynamic linking on AIX
Previous:From: Pavel StehuleDate: 2006-09-15 07:31:17
Subject: Re: plpgsql, return can contains any expression

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