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

Re: why can't plpgsql return a row-expression?

From: Asif Rehman <asifr(dot)rehman(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: why can't plpgsql return a row-expression?
Date: 2012-11-12 13:50:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

I have tried to solve this issue. Please see the attached patch.

With this patch, any expression is allowed in the return statement. For any
invalid expression an error is generated without doing any special handling.
When a row expression is used in the return statement then the resultant
tuple will have rowtype in a single column that needed to be extracted.
Hence I have handled that case in exec_stmt_return().

any comments/suggestions?


On Mon, Oct 8, 2012 at 9:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

Attachment: return_rowtype.patch
Description: application/octet-stream (9.5 KB)

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-11-12 14:17:01
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Previous:From: Markus WannerDate: 2012-11-12 10:13:43
Subject: Re: Enabling Checksums

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