From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
Cc: | Sim Zacks <sim(at)compulab(dot)co(dot)il>, ebehn(at)arinc(dot)com, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: Array of composite types returned from python |
Date: | 2014-06-29 20:54:03 |
Message-ID: | 4575.1404075243@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> writes:
>> 3) This is such a simple change with no new infrastructure code
>> (PLyObject_ToComposite already exists). Can you think of a reason
>> why this wasn't done until now? Was it a simple miss or purposefully
>> excluded?
> This is not an authoritative answer: I think the infrastructure was
> originally missing, but was later added in #bc411f25 for OUT parameters.
> Perhaps it was overlooked at the time that the same code would suffice
> for this earlier-missing case. (I've Cc:ed Peter E. in case he has any
> comments.)
> I think the patch is ready for committer.
I took a quick look at this; not really a review either, but I have
a couple comments.
1. While I think the patch does what it intends to, it's a bit distressing
that it will invoke the information lookups in PLyObject_ToComposite over
again for *each element* of the array. We probably ought to quantify that
overhead to see if it's bad enough that we need to do something about
improving caching, as speculated in the comment in PLyObject_ToComposite.
2. I wonder whether the no-composites restriction in plpy.prepare
(see lines 133ff in plpy_spi.c) could be removed as easily.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-06-29 21:19:47 | Re: idle_in_transaction_timeout |
Previous Message | Simon Riggs | 2014-06-29 20:38:54 | Re: SKIP LOCKED DATA (work in progress) |