Re: 9.3: Empty arrays returned by array_remove()

From: Noah Misch <noah(at)leadboat(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.3: Empty arrays returned by array_remove()
Date: 2013-06-01 01:57:48
Message-ID: 20130601015748.GA244722@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 31, 2013 at 08:55:49AM +0100, Dean Rasheed wrote:
> On 31 May 2013 08:34, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> > On 31 May 2013 02:52, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> >> Testing 9.3beta, it seems that array_remove() may return an empty 1-d
> >> array whose upper bound is lower than its lower bound. I know that we
> >> discussed allowing this kind of array, but I don't think that
> >> discussion reached any conclusion, other than to agree that the
> >> current empty 0-d array behaviour would be kept in 9.3.
> >
> > That's right, zero-D is still the only supported representation of an
> > empty array, so when array_remove() yields an empty array it ought to
> > be zero-D. Good catch.
>
> Yeah, that's what I thought. Here's a patch to fix it, plus a new
> regression test to confirm that the result is a zero-D array.

Committed. Thanks.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-06-01 02:31:02 Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Previous Message Bruce Momjian 2013-06-01 01:49:23 Re: Running pgindent