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. 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? > > - Heikki > >
