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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
