Re: Add support for SRF and returning composites to pl/tcl

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

In response to

Responses

Browse pgsql-hackers by date

  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 …