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

Hi,

PL/pgsql seems to have a strange restriction regarding "RETURN".
Normally, you can write "RETURN <expression>". But if the function
returns a row type, then you can only write "RETURN variable" or
"RETURN NULL".

rhaas=# create type xyz as (a int, b int);
CREATE TYPE
rhaas=# select row(1,2)::xyz;
row
-------
(1,2)
(1 row)

rhaas=# create or replace function return_xyz() returns xyz as $$
rhaas$# begin
rhaas$# return row(1,2)::xyz;
rhaas$# end$$ language plpgsql;
ERROR: RETURN must specify a record or row variable in function returning row
LINE 3: return row(1,2)::xyz;
^

Off the top of my head, I can't think of any reason for this
restriction, nor can I find any code comments or anything in the
commit log which explains the reason for it. Does anyone know why we
don't allow this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ERROR: RETURN must specify a record or row variable in function returning row

> Off the top of my head, I can't think of any reason for this
> restriction, nor can I find any code comments or anything in the
> commit log which explains the reason for it. Does anyone know why we
> don't allow this?

Laziness, probably. Feel free to have at it.

regards, tom lane

2012/10/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ERROR: RETURN must specify a record or row variable in function returning row
>
>> Off the top of my head, I can't think of any reason for this
>> restriction, nor can I find any code comments or anything in the
>> commit log which explains the reason for it. Does anyone know why we
>> don't allow this?
>
> 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.

Pavel

>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/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

Hi,

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?

Regards,
--Asif

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:
> http://www.postgresql.org/mailpref/pgsql-hackers
>