From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: why can't plpgsql return a row-expression? |
Date: | 2012-10-08 16:53:10 |
Message-ID: | 3567.1349715190@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2012/10/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Laziness, probably. Feel free to have at it.
> I wrote patch some years ago. It was rejected from performance reasons
> - because every row had to be casted to resulted type.
I don't recall that patch in any detail, but it's not apparent to me
that an extra cast step *must* be required to implement this. In the
cases that are supported now, surely we could notice that no additional
work is required.
It's also worth commenting that if we were to switch the storage of
composite-type plpgsql variables to HeapTuple, as has been suggested
here for other reasons, the performance tradeoffs in this area would
likely change completely anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2012-10-08 17:56:58 | Re: Bad Data back Door |
Previous Message | Tom Lane | 2012-10-08 16:49:19 | Re: Logging parameters values on bind error |