From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add support for SRF and returning composites to pl/tcl |
Date: | 2016-11-06 18:15:28 |
Message-ID: | 8785.1478456128@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Franck Verrot | 2016-11-06 20:20:37 | Re: Mention column name in error messages |
Previous Message | Artur Zakirov | 2016-11-06 17:48:18 | Re: [HACKERS] Re: [PATCH] Tab completion for ALTER TYPE … RENAME VALUE … |