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

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-10 05:58:51
Message-ID: BAY20-F184BC44EC5D665CF2BCEE8F9660@phx.gbl (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
>- we can't use estate->rsi for the RETURN case, at least as presently
>implemented, because that is not always filled-out -- the example I gave
>before shows how because we don't check for a compatible TupleDesc when
>estate->rsi is NULL, we end up returning a value that is incompatible
>with the function's declared return type

I expected so when rsi is NULL, then I haven't any info about desired record 
type, and then I have to skip checking for a compatibility (and I can it to 
do, because this is clean error, then is not necessery conversion, and next 
step do exception and error if returned type is wrong).

I found different problem. It has maybe relation with Tom Lane's changes 
about returning one field records. And maybe wee need test for conversion 

create or replace function a() returns record as $$ return (1); $$ language 

is syntax clean, it's row expression, but select a() ends with wrong result 
type supplied in RETURN. With change return (1,2), all works fine. return 
row(1) works well too.

>- therefore, we need to use some other way to get the TupleDesc of the
>function's declared return type. Offhand I think we can use
>estate->fn_rettype (plus the funcapi stuff for handling RECORDOID), but
>I haven't had a chance to try it yet.

testing estate->fn_rettype is safer, but what is efectivity? Is necessery 
caching TupleDesc in retturn statement? I don't know? I don't study 
mechanism when is rsi valid or not. But I found some samples in source, when 
rsi was used for same purpose.


Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.

In response to


pgsql-patches by date

Next:From: Hiroshi SaitoDate: 2005-11-10 11:20:57
Subject: wishes correction of postgresql.conf.sample.
Previous:From: Tom LaneDate: 2005-11-09 22:42:32
Subject: Re: Reducing the overhead of NUMERIC data

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