Re: Bad behavior from plpython 'return []'

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

In response to

Responses

Browse pgsql-hackers by date

  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)