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-F28A98DD2C8DCAA2AE32C2F9820@phx.gbl Whole thread Raw |
In response to | Re: return can contains any row or record functions (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: return can contains any row or record functions
|
List | pgsql-patches |
Not from my side Regards Pavel Stehule >From: Bruce Momjian <pgman@candle.pha.pa.us> >To: Pavel Stehule <pavel.stehule@hotmail.com> >CC: neilc@samurai.com, pgsql-patches@postgresql.org >Subject: Re: [PATCHES] return can contains any row or record functions >Date: Wed, 14 Jun 2006 18:48:00 -0400 (EDT) > > >Has any more work happened on this patch? > >--------------------------------------------------------------------------- > >Pavel Stehule wrote: > > > > >- 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 > > everytime > > > > create or replace function a() returns record as $$ return (1); $$ >language > > plpgsql; > > > > 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. > > > > Pavel > > > > _________________________________________________________________ > > Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. > > http://messenger.msn.cz/ > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faq > > > >-- > Bruce Momjian http://candle.pha.pa.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > >---------------------------(end of broadcast)--------------------------- >TIP 4: Have you searched our list archives? > > http://archives.postgresql.org _________________________________________________________________ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/
pgsql-patches by date: