Re: BUG #7730: intarray representation of empty arrays - Mailing list pgsql-bugs
From | Bruce Momjian |
---|---|
Subject | Re: BUG #7730: intarray representation of empty arrays |
Date | |
Msg-id | 20130907154447.GD11757@momjian.us Whole thread Raw |
In response to | Re: BUG #7730: intarray representation of empty arrays (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: BUG #7730: intarray representation of empty arrays
|
List | pgsql-bugs |
Applied. --------------------------------------------------------------------------- On Wed, Sep 4, 2013 at 03:01:50PM -0400, Bruce Momjian wrote: > On Wed, Dec 5, 2012 at 12:44:39AM +0000, elein@varlena.com wrote: > > The following bug has been logged on the website: > > > > Bug reference: 7730 > > Logged by: elein > > Email address: elein@varlena.com > > PostgreSQL version: 9.2.1 > > Operating system: Linux > > Description: > > > > select NULLIF('{1,2,3}'::integer[] - '{3,2,1}'::integer[], '{}'::integer[]); > > This returns an empty array. It should return NULL. > > > > Per RhodiumToad: the core code represents '{}' as an array with 0 > > dimensions, whereas intarray represents it as an array with 1 dimension but > > 0 elements > > > > intarray should use the same standards as the core code if possible. I > > peered at the code and don't see anything untoward but did not have time to > > spend on it. > > I just got time to look at this, and it is certainly easier to see when > you use array_dims(): > > SELECT '{1,2,3}'::integer[] - '{3,2,1}'::integer[]; > ?column? > ---------- > {} > > SELECT array_dims('{1,2,3}'::integer[] - '{3,2,1}'::integer[]); > array_dims > ------------ > [1:0] > > SELECT array_dims('{}'::integer[]); > array_dims > ------------ > (null) > > This is part of the larger TODO item of how to handle empty > >=1-dimensional empty arrays vs. zero-dimensional empty arrays, which is > discussed here: > > https://wiki.postgresql.org/wiki/Todo#Arrays > Improve handling of empty arrays > > In that thread, no one could find a way to create a 1-dimensional empty > array at the SQL level, but thanks to intarray, you found a way. It is > natural that intarray, being mostly used for one-dimensional arrays, > would return a 1-dimensional empty array. However, besides being > inconsistent, as you mentioned, there is also no way to dump/restore > one-dimensional empty arrays, which is a larger concern. > > I have developed the attached patch to force empty intarray results to > be zero-dimensional empty arrays, rather than 1-dimensional empty > arrays. With this patch, a zero-dimensional empty array is returned: > > SELECT array_dims('{1,2,3}'::integer[] - '{3,2,1}'::integer[]); > array_dims > ------------ > (null) > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > diff --git a/contrib/intarray/_int_tool.c b/contrib/intarray/_int_tool.c > new file mode 100644 > index 8635576..fc462b2 > *** a/contrib/intarray/_int_tool.c > --- b/contrib/intarray/_int_tool.c > *************** resize_intArrayType(ArrayType *a, int nu > *** 246,251 **** > --- 246,258 ---- > int nbytes = ARR_DATA_OFFSET(a) + sizeof(int) * num; > int i; > > + /* if no elements, return a zero-dimensional array */ > + if (num == 0) > + { > + ARR_NDIM(a) = 0; > + return a; > + } > + > if (num == ARRNELEMS(a)) > return a; > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
pgsql-bugs by date: