2016-10-11 7:49 GMT+02:00 Heikki Linnakangas <hlinn...@iki.fi>: > On 10/10/2016 08:42 PM, Pavel Stehule wrote: > >> 2016-10-10 12:31 GMT+02:00 Heikki Linnakangas <hlinn...@iki.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 > >
