Re: return can contains any row or record functions

From: "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com>
To: neilc(at)samurai(dot)com
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: return can contains any row or record functions
Date: 2005-11-08 07:55:03
Message-ID: BAY20-F23715C7B79CA5DBAFBACB5F9640@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

>From: Neil Conway <neilc(at)samurai(dot)com>
>To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
>CC: pgsql-patches(at)postgresql(dot)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/

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Atsushi Ogawa 2005-11-08 14:37:49 Improve the comparison of NUMERIC data
Previous Message Neil Conway 2005-11-07 23:10:13 Re: return can contains any row or record functions