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 01:12:20 |
Message-ID: | 8658.1478394740@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> Attached is a patch that adds support for SRFs and returning composites
> from pl/tcl. This work was sponsored by Flight Aware.
I spent a fair amount of time whacking this around, because I did not
like the fact that you were using the pltcl_proc_desc structs for
call-local data. That would fail nastily in a recursive function.
I ended up making a new struct to represent per-call data, which
allowed reducing the number of global pointers.
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?
I wouldn't necessarily object to allowing either representation, though
I'm not sure how we'd distinguish between them.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
pltcl_srf_composite_3.patch | text/x-diff | 37.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-11-06 05:09:58 | Re: Add support for SRF and returning composites to pl/tcl |
Previous Message | Pavel Stehule | 2016-11-05 20:39:47 | Re: Add support for SRF and returning composites to pl/tcl |