On 11/6/16 12:15 PM, Tom Lane wrote:
> I wrote:
>> I got the code to a state that I liked (attached), and started reviewing
>> the docs, and then it occurred to me to wonder why you'd chosen to use
>> Tcl lists to represent composite output values. The precedent established
>> by input argument handling is that composites are transformed to Tcl
>> arrays. So shouldn't we use an array to represent a composite result,
>> too?
>
> After further nosing around I see that the return-a-tuple-as-a-list
> concept is already embedded in pltcl_trigger_handler. So the
> inconsistency is already there, and it's not necessarily this patch's
> job to fix it. Still seems like we might want to allow using an array
> directly rather than insisting on conversion to a list, but that's a
> task for a separate patch.
My understanding is that the TCL community is of mixed feelings when it
comes to arrays vs lists. It does seem worth adding array support though.
> We should, however, make some attempt to ensure that the list-to-tuple
> conversion semantics are the same in both cases. In particular I notice
> some undocumented behavior around a magic ".tupno" element. Will see
> about cleaning that up.
Hrm, I completely spaced on the fact that composite returns are
essentially the same thing as trigger returns. ISTM we should be able to
use the same code for both. IIRC those magic elements could end up in
any SPI result, so that handling certainly needs to be the same.
Have you had a chance to look at this or should I?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461