From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bad behavior from plpython 'return []' |
Date: | 2016-07-01 19:52:12 |
Message-ID: | 27597.1467402732@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jun 30, 2016 at 9:25 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-07-01 20:34:58 | Re: Bad behavior from plpython 'return []' |
Previous Message | Peter Geoghegan | 2016-07-01 19:37:23 | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) |