|From:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>|
|To:||Dave Cramer <pg(at)fastcrypt(dot)com>|
|Cc:||Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alexey Grishchenko <programmerag(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: PL/Python adding support for multi-dimensional arrays|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 09/27/2016 02:04 PM, Dave Cramer wrote:
> On 26 September 2016 at 14:52, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>>> This crashes with arrays with non-default lower bounds:
>>> postgres=# SELECT * FROM test_type_conversion_array_int
>>> INFO: ([1, 2, <NULL>], <type 'list'>)
>>> server closed the connection unexpectedly
>>> This probably means the server terminated abnormally
>>> before or while processing the request.
>>> Attached patch fixes this bug, and adds a test for it.
I spent some more time massaging this:
* Changed the loops from iterative to recursive style. I think this
indeed is slightly easier to understand.
* Fixed another segfault, with too deeply nested lists:
CREATE or replace FUNCTION test_type_conversion_mdarray_toodeep()
RETURNS int AS $$
$$ LANGUAGE plpythonu;
* Also, in PLySequence_ToArray(), we must check that the 'len' of the
array doesn't overflow.
* Fixed reference leak in the loop in PLySequence_ToArray() to count the
number of dimensions.
>>> I'd like to see some updates to the docs for this. The manual doesn't
>>> currently say anything about multi-dimensional arrays in pl/python, but it
>>> should've mentioned that they're not supported. Now that it is supported,
>>> should mention that, and explain briefly that a multi-dimensional array is
>>> mapped to a python list of lists.
>> If the code passes I'll fix the docs
Please do, thanks!
|Next Message||Tom Lane||2016-09-27 19:01:53||Re: Detect supported SET parameters when pg_restore is run|
|Previous Message||Kevin Grittner||2016-09-27 17:35:49||Re: Floating point comparison inconsistencies of the geometric types|