Re: PL/Python adding support for multi-dimensional arrays

On 09/22/2016 10:28 AM, Pavel Stehule wrote:
> Now, the tests are enough - so I'll mark this patch as ready for commiters.
>
> I had to fix tests - there was lot of white spaces, and the result for
> python3 was missing

Thanks Pavel!

This crashes with arrays with non-default lower bounds:

postgres=# SELECT * FROM test_type_conversion_array_int4('[2:4]={1,2,3}');
INFO: ([1, 2, <NULL>], <type 'list'>)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

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.

It seems we don't have any mention in the docs about arrays with
non-default lower-bounds ATM. That's not this patch's fault, but it
would be good to point out that the lower bounds are discarded when an
array is passed to python.

I find the loop in PLyList_FromArray() quite difficult to understand.
Are the comments there mixing up the "inner" and "outer" dimensions? I
wonder if that would be easier to read, if it was written in a
recursive-style, rather than iterative with stacks for the dimensions.

On 08/03/2016 02:49 PM, Alexey Grishchenko wrote:
> This patch does not support multi-dimensional arrays of composite types, as
> composite types in Python might be represented as iterators and there is no
> obvious way to find out when the nested array stops and composite type
> structure starts. For example, if we have a composite type of (int, text),
> we can try to return "[ [ [1,'a'], [2,'b'] ], [ [3,'c'], [4,'d'] ] ]", and
> it is hard to find out that the first two lists are lists, and the third
> one represents structure. Things are getting even more complex when you
> have arrays as members of composite type. This is why I think this
> limitation is reasonable.

How do we handle single-dimensional arrays of composite types at the
moment? At a quick glance, it seems that the composite types are just
treated like strings, when they're in an array. That's probably OK, but
it means that there's nothing special about composite types in
multi-dimensional arrays. In any case, we should mention that in the docs.

- Heikki