Re: [HACKERS] Bad behavior from plpython 'return []'
On 7/1/16 2:52 PM, Tom Lane wrote: + /* if caller tries to specify zero-length array, make it empty */ + if (nelems <= 0) + return construct_empty_array(elmtype); + /* compute required space */ nbytes = 0; hasnulls = false; But that might introduce new problems too, if any callers expect the array dimensions to be exactly what they asked for. You mean ndims? What if instead of an empty array it returned an array where *dims was just all zeros (and correctly set *lbs)? array_eq would still need to account for that, but I think we don't have a choice about that unless we expressly forbid arrays where any of the elements of *dims were 0 (which I suspect we should probably do anyway... I don't see how you can do anything with a 2x0x3 array...) -- 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bad behavior from plpython 'return []'
Robert Haas writes: > On Thu, Jun 30, 2016 at 9:25 PM, Jim Nasby wrote: >> SELECT array_dims(pg_temp.bad()), array_dims('{}'::text[]); >> array_dims | array_dims >> + >> [1:0] | >> (1 row) > Yeah, that's a bug. It looks like this is because PLySequence_ToArray neglects to special-case zero-element arrays. We could fix it there, but this is not the first such bug. I wonder if we should change construct_md_array to force zero-element arrays to be converted to empty arrays, rather than assuming callers will have short-circuited the case earlier. Something like /* fast track for empty array */ if (ndims == 0) return construct_empty_array(elmtype); nelems = ArrayGetNItems(ndims, dims); + /* if caller tries to specify zero-length array, make it empty */ + if (nelems <= 0) + return construct_empty_array(elmtype); + /* compute required space */ nbytes = 0; hasnulls = false; But that might introduce new problems too, if any callers expect the array dimensions to be exactly what they asked for. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bad behavior from plpython 'return []'
On Thu, Jun 30, 2016 at 9:25 PM, Jim Nasby wrote: > 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) Yeah, that's a bug. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers