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