Re: return can contains any row or record functions

OK, but it seemed the patch needed more work before it could be applied.
I added a TODO item for it:

o Allow PL/RETURN to return row or record functions

http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php

---------------------------------------------------------------------------

Pavel Stehule wrote:
> Not from my side
>
> Regards
> Pavel Stehule
>
>
> >From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
> >To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
> >CC: neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)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/
>
>
> ---------------------------(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. +