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

SELECT pg_temp.bad() = '{}'::text[];
(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!
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to