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

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(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
Date: 2016-10-10 23:47:19
Message-ID: CADK3HH+7Swwdd+p02hpH7ipY6OLiOL+Sm2HrLGEwa1wFvn42WA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 October 2016 at 13:42, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 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.
>
> Regards
>
> Pavel
>
>
>>
>> I think we should bite the bullet and do that anyway. As long as it's
>> clearly documented, and the error message you get contains a clear hint on
>> how to fix it, I don't think it would be too painful to adjust existing
>> application.
>>
>> We could continue to accept a Python list for a plain composite type,
>> this would only affect arrays of composite types.
>>
>> I don't use PL/python much myself, so I don't feel qualified to make the
>> call, though. Any 3rd opinions?
>
>
Can't you determine the correct output based on the function output
definition ?

For instance if the function output was an array type then we would return
the list as an array
if the function output was a set of then we return tuples ?

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-10-10 23:50:18 Re: FSM corruption leading to errors
Previous Message Thomas Munro 2016-10-10 23:20:39 Re: De-support SCO OpenServer/SCO UnixWare?