Bad behavior from plpython 'return []'

CREATE FUNCTION pg_temp.bad() RETURNS text[] LANGUAGE plpythonu AS
$$return []$$;
SELECT pg_temp.bad();
bad
-----
{}
(1 row)

SELECT pg_temp.bad() = '{}'::text[];
?column?
----------
f
(1 row)

Erm?? Turns out this is because

SELECT array_dims(pg_temp.bad()), array_dims('{}'::text[]);
array_dims | array_dims
------------+------------
[1:0] |
(1 row)

and array_eq does this right off the bat:

> /* fast path if the arrays do not have the same dimensionality */
> if (ndims1 != ndims2 ||
> memcmp(dims1, dims2, ndims1 * sizeof(int)) != 0 ||
> memcmp(lbs1, lbs2, ndims1 * sizeof(int)) != 0)
> result = false;

plpython is calling construct_md_array() with ndims set to 1, *lbs=1 and
(I'm pretty sure) *dims=0. array_in throws that combination out as
bogus; I think that construct_md_array should at least assert() that as
well. It's only used in a few places outside of arrayfuncs.c, but I find
it rather disturbing that an included PL has been broken in this fashion
for quite some time (PLySequence_ToArray() is the same in 9.0). There's
at least one plpython unit test that would have thrown an assert.

plperl appears to be immune from this because it calls
accumArrayResult() inside a loop that shouldn't execute for a 0 length
array. Would that be the preferred method of building arrays in
plpython? ISTM that'd be wasteful since it would incur a useless copy
for everything that's varlena (AFAICT plperl already suffers from this).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461