From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Better support for whole-row operations and composite |
Date: | 2004-04-03 06:00:54 |
Message-ID: | 406E5316.2080808@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:
>> /* 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-03 06:25:40 | Re: Better support for whole-row operations and composite types |
Previous Message | Tom Lane | 2004-04-03 05:02:27 | Re: Better support for whole-row operations and composite types |