Re: Add support for SRF and returning composites to pl/tcl - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Add support for SRF and returning composites to pl/tcl
Date
Msg-id CAFj8pRBXDer-Ztpefnz+oYNPD9UCVg-XyteGTBQihM2TNRY3Qg@mail.gmail.com
Whole thread Raw
In response to Re: Add support for SRF and returning composites to pl/tcl  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2016-11-06 2:12 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Jim Nasby <Jim.Nasby@BlueTreble.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?

This can be similar to PLPythonu - one dimensional array is possible to transform to composite - when composite is expected.

Regards

Pavel

 

I wouldn't necessarily object to allowing either representation, though
I'm not sure how we'd distinguish between them.

                        regards, tom lane



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add support for SRF and returning composites to pl/tcl
Next
From: Michael Paquier
Date:
Subject: Re: commitfest 2016-11 status summary