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

On 09/23/2016 10:27 PM, Jim Nasby wrote:
> On 9/23/16 2:42 AM, Heikki Linnakangas wrote:
>> 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.
>
> That is how they're handled, but I'd really like to change that. I've
> held off because I don't know how to handle the backwards
> incompatibility that would introduce. (I've been wondering if we might
> add a facility to allow specifying default TRANSFORMs that should be
> used for specific data types in specific languages.)
>
> The converse case (a composite with arrays) suffers the same problem
> (array is just treated as a string).

I take that back, I don't know what I was talking about. Without this
patch, an array of composite types can be returned, using any of the
three representations for the composite type explained in the docs: a
string, a sequence, or a dictionary. So, all these work, and return the
same value:

create table foo (a int4, b int4);

CREATE FUNCTION comp_array_string() RETURNS foo[] AS $$
return ["(1, 2)"]
$$ LANGUAGE plpythonu;

CREATE FUNCTION comp_array_sequence() RETURNS foo[] AS $$
return [[1, 2]]
$$ LANGUAGE plpythonu;

CREATE FUNCTION comp_array_dict() RETURNS foo[] AS $$
return [{"a": 1, "b": 2}]
$$ LANGUAGE plpythonu;

Jim, I was confused, but you agreed with me. Were you also confused, or
am I missing something?

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?

The string and dict representations don't have that ambiguity at all, so
I don't see why we wouldn't support those, at least.

- Heikki