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/
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 |