Re: Better support for whole-row operations and composite - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Better support for whole-row operations and composite
Date
Msg-id 406E5316.2080808@joeconway.com
Whole thread Raw
In response to Re: Better support for whole-row operations and composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better support for whole-row operations and composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> /* for tuple args, convert to a one row data.frame */ 
>> TupleTableSlot *slot = (TupleTableSlot *) arg[i]; HeapTuple        tuples
>> = slot->val; TupleDesc        tupdesc = slot->ttc_tupleDescriptor;
> 
> Um.  Well, the arg is not a TupleTableSlot * anymore, so this is 
> guaranteed to fail.  This isn't part of what I thought the documented
>  SRF API was though.

I'm sure you're correct. The SRF API was for user defined functions, not
procedural languages anyway. I'll look at how the other procedural
languages handle tuple arguments.

> If you take the arg[i] value and pass it to GetAttributeByName or
> GetAttributeByNum it will work (with some compiler warnings) and
> AFAICS we never documented more than that.

OK, thanks,

Joe



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Better support for whole-row operations and composite types
Next
From: Tom Lane
Date:
Subject: Re: Better support for whole-row operations and composite types