Re: Accessing original TupleDesc from SRF

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Gray <jgray(at)azuli(dot)co(dot)uk>, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Accessing original TupleDesc from SRF
Date: 2002-08-31 18:38:43
Message-ID: 3D710D33.4080605@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>Attached adds:
>> + TupleDesc queryDesc; /* descriptor for planned query */
>>to ReturnSetInfo, and populates ReturnSetInfo for every function call to
>> ExecMakeTableFunctionResult, not just when fn_retset.
>
> I thought "expectedDesc" was a more sensible choice of name, so I made
> it that. Otherwise, patch applied.

I was trying to actually use this new feature today, and ran into a
little bug in nodeFunctionscan.c that prevented it from actually working.

For anonymous composite types, ExecInitFunctionScan builds the tuple
description using:
tupdesc = BuildDescForRelation(coldeflist);

But BuildDescForRelation leaves initializes the tupdesc like this:
desc = CreateTemplateTupleDesc(natts, UNDEFOID);

The UNDEFOID later causes an assertion failure in heap_formtuple when
you try to use the tupdesc to build a tuple.

Attached is a very small patch to fix.

>>I haven't done it yet, but I suppose this should be documented in
>>xfunc.sgml.
> Actually, most of what's in src/backend/utils/fmgr/README should be
> transposed into xfunc.sgml someday.

After beta starts I'll work on migrating this to the sgml docs.

Joe

Attachment Content-Type Size
anontyp-bugfix.1.patch text/plain 657 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-31 18:55:03 Re: source code indexer
Previous Message Iavor Raytchev 2002-08-31 17:55:49 pgaccess 0.98.8 beta 1 - the show starts