I wrote:
Ronan Dunklau ronan.dunk...@dalibo.com writes:
I don't know how to do that without implementing the cache itself.
I don't either, but my thought was that we could hack up a simple
one-element cache pretty trivially, eg static info and desc variables
in PLyObject_ToComposite that are
Le dimanche 29 juin 2014 16:54:03 Tom Lane a écrit :
Abhijit Menon-Sen a...@2ndquadrant.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
Hi Ronan.
Based on your review, I'm marking this as ready for committer.
The attached patch implements this.
Your patch looks sensible enough (thanks for adding tests), but I guess
we'll let the reviewer sort out whether to commit the original or your
extended version.
Thanks.
-- Abhijit
Ronan Dunklau ronan.dunk...@dalibo.com writes:
Le dimanche 29 juin 2014 16:54:03 Tom Lane a =E9crit :
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
] Array of composite types returned from python
Abhijit Menon-Sen a...@2ndquadrant.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
Hi.
When this patch was first added to a CF, I had a quick look at it, but
left it for a proper review by someone more familiar with PL/Python
internals for precisely this reason:
2) You removed the comment:
- /*
- * We don't support arrays of row
At 2014-06-29 18:08:53 +0530, a...@2ndquadrant.com wrote:
I think the patch is ready for committer.
That's based on my earlier quick look and the current archaeology. But
I'm not a PL/Python user, and Ronan signed up to review the patch, so I
haven't changed the status.
Ronan, did you get a
Abhijit Menon-Sen a...@2ndquadrant.com writes:
I had another look now, and I think removing the comment is fine. It
actually made no sense to me in context, so I went digging a little.
...
Note that the first argument was actually NULL, so the comment made
sense when it was written. But the
Abhijit Menon-Sen a...@2ndquadrant.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:
Am I missing anything, (ie memory leak, undesirable behavior elsewhere)?
-Ed
I applied the patch and it looks like it is working well. As a longtime
plpython user, I appreciate the fix.
I have a few comments:
1) I would remove the error message from the PO files as well.
2) You removed
20, 2014 5:54 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Array of composite types returned from python
I've endeavored to enable the return of arrays of composite types from code
written in PL/Python. It seems that this can be accomplished though a very
minor change to the code
On Thu, Mar 20, 2014 at 4:54 PM, Behn, Edward (EBEHN) eb...@arinc.com wrote:
I've endeavored to enable the return of arrays of composite types from code
written in PL/Python. It seems that this can be accomplished though a very
minor change to the code:
On line 401 in the file
I've endeavored to enable the return of arrays of composite types from code
written in PL/Python. It seems that this can be accomplished though a very
minor change to the code:
On line 401 in the file src/pl/plpython/plpy_typeio.c, remove the error
report PL/Python functions cannot return
13 matches
Mail list logo
