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

2016-10-11 7:49 GMT+02:00 Heikki Linnakangas <hlinnaka(at)iki(dot)fi>:

> On 10/10/2016 08:42 PM, Pavel Stehule wrote:
>
>> 2016-10-10 12:31 GMT+02:00 Heikki Linnakangas <hlinnaka(at)iki(dot)fi>:
>>
>> On 10/01/2016 02:45 AM, Jim Nasby wrote:
>>>
>>> On 9/29/16 1:51 PM, Heikki Linnakangas wrote:
>>>>
>>>> Now, back to multi-dimensional arrays. I can see that the Sequence
>>>>> representation is problematic, with arrays, because if you have a
>>>>> python
>>>>> list of lists, like [[1, 2]], it's not immediately clear if that's a
>>>>> one-dimensional array of tuples, or two-dimensional array of integers.
>>>>> Then again, we do have the type definitions available. So is it really
>>>>> ambiguous?
>>>>>
>>>>>
>>>> [[1,2]] is a list of lists...
>>>> In [4]: b=[[1,2]]
>>>>
>>>> In [5]: type(b)
>>>> Out[5]: list
>>>>
>>>> In [6]: type(b[0])
>>>> Out[6]: list
>>>>
>>>> If you want a list of tuples...
>>>> In [7]: c=[(1,2)]
>>>>
>>>> In [8]: type(c)
>>>> Out[8]: list
>>>>
>>>> In [9]: type(c[0])
>>>> Out[9]: tuple
>>>>
>>>>
>>> Hmm, so we would start to treat lists and tuples differently? A Python
>>> list would be converted into an array, and a Python tuple would be
>>> converted into a composite type. That does make a lot of sense. The only
>>> problem is that it's not backwards-compatible. A PL/python function that
>>> returns an SQL array of rows, and does that by returning Python list of
>>> lists, it would start failing.
>>>
>>
>> is not possible do decision in last moment - on PL/Postgres interface?
>> There the expected type should be known.
>>
>
> Unfortunately there are cases that are fundamentally ambiguous.
>
> create type comptype as (intarray int[]);
> create function array_return() returns comptype[] as $$
> return [[[[1]]]];
> $$ language plpython;
>
> What does the function return? It could be two-dimension array of
> comptype, with a single-dimension intarray, or a single-dimension comptype,
> with a two-dimension intarray.
>
> We could resolve it for simpler cases, but not the general case. The
> simple cases would probably cover most things people do in practice. But if
> the distinction between a tuple and a list feels natural to Python
> programmers, I think it would be more clear in the long run to have people
> adjust their applications.
>

I agree. The distinction is natural - and it is our issue, so we don't
distinguish strongly.

Regards

Pavel

>
> - Heikki
>
>