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


---------------------------(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. +

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 12 | next ›
Discussion Overview
grouppgsql-patches @
categoriespostgresql
postedNov 7, '05 at 1:58p
activeJun 16, '06 at 6:18a
posts12
users4
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2017 Grokbase