Re: return can contains any row or record functions - Mailing list pgsql-patches

From Pavel Stehule
Subject Re: return can contains any row or record functions
Date
Msg-id BAY20-F23715C7B79CA5DBAFBACB5F9640@phx.gbl
Whole thread Raw
In response to Re: return can contains any row or record functions  (Neil Conway <neilc@samurai.com>)
Responses Re: return can contains any row or record functions  (Neil Conway <neilc@samurai.com>)
List pgsql-patches


>From: Neil Conway <neilc@samurai.com>
>To: Pavel Stehule <pavel.stehule@hotmail.com>
>CC: pgsql-patches@postgresql.org
>Subject: Re: [PATCHES] return can contains any row or record functions
>Date: Mon, 07 Nov 2005 18:10:13 -0500
>
>I'm confused by this part of the patch, circa line 1835 of pl_exec.c:
>
>/* coerce type if needed */
>if (estate->rsi && IsA(estate->rsi, ReturnSetInfo) &&
>     estate->rsi->expectedDesc != NULL &&
>     !compatible_tupdesc(estate->rsi->expectedDesc, in_tupdesc))
>{
>     estate->retval = (Datum) make_tuple_from_tuple(estate,
>                                                    &td,
>                                                    in_tupdesc,
>                    estate->rsi->expectedDesc);
>     if (estate->retval == PointerGetDatum(NULL))
>    ereport(...);
>
>     estate->rettupdesc = estate->rsi->expectedDesc;
>}
>else
>{
>     estate->retval = (Datum) heap_copytuple(&td);
>     estate->rettupdesc = in_tupdesc;
>}
>
>This is for the "tuple returning function" case of RETURN. estate->rsi
>seems to contain information for set-returning functions -- why do we
>need to use it to obtain the expected tupledesc of the function's return
>value? I'm just wondering if we ought to be fetching this from somewhere
>else.
>

example:
create anyfce() returns record|type ....

select anyfce0(); -- ok without conversion
select * from anyfce0() as (RSIX) --> PROBLEM1 without conversion (I have
rsix or rsiy)

create anyfce1() returns record ..
   return next anyfce0()
..

select * from anyfce1() as (RSIY) --> PROBLEM2 without conversion

PL/pgSQL haven't statement for corversion, and I have to do it.  I added
last this conversion when I did regress test. Generally I don't need this
variability without one exception: working with trigger variables NEW, OLD.

>As it stands, this seems plainly wrong:
>
>create type __trt as (x integer, y integer, z text);
>
>create or replace function return_row4() returns __trt as $$
>begin
>   return (1,2,'3'::text,4);
>end;
>$$ language plpgsql;
>
>select return_row4();
>  return_row4
>-------------
>  (1,2,3,4)
>(1 row)
>

the situation is clean in this example, but when I forward any diferent row
I can have problems. When I allowed only row function or row expression ()
all was ok. But it's havy limit, and I allowed any row or record function
--> need implicit conversion. And it's very propably so return next will
contain row function, no?

Sorry for my ugly english.

Pavel

_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/


pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: return can contains any row or record functions
Next
From: Atsushi Ogawa
Date:
Subject: Improve the comparison of NUMERIC data