From: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> |
---|---|
To: | pgman(at)candle(dot)pha(dot)pa(dot)us |
Cc: | neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: return can contains any row or record functions |
Date: | 2006-06-15 05:04:02 |
Message-ID: | BAY20-F28A98DD2C8DCAA2AE32C2F9820@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2006-06-15 06:09:43 | Re: Test request for Stats collector performance improvement |
Previous Message | Pavel Stehule | 2006-06-15 05:02:55 | Re: SQL/XML publishing function experimental patch II |