Re: BUG #7730: intarray representation of empty arrays
| От | Elein |
|---|---|
| Тема | Re: BUG #7730: intarray representation of empty arrays |
| Дата | |
| Msg-id | E42B9990-344B-47A4-ADEE-95F1250B966B@varlena.com обсуждение исходный текст |
| Ответ на | Re: BUG #7730: intarray representation of empty arrays (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: BUG #7730: intarray representation of empty arrays
Re: BUG #7730: intarray representation of empty arrays |
| Список | pgsql-bugs |
Thanks for looking into this. Finally I'll get to test existing columns fil=
led with a variety of array[0], '{}' and array[0]-array[0] or Null. Sorry it=
took so long.=20
What is the target production release?
A. Elein Mustain
Elein@varlena.com
510-637-9106
> On Sep 7, 2013, at 8:44 AM, Bruce Momjian <bruce@momjian.us> wrote:
>=20
>=20
> Applied.
>=20
> --------------------------------------------------------------------------=
-
>=20
>> 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:
>>>=20
>>> Bug reference: 7730
>>> Logged by: elein
>>> Email address: elein@varlena.com
>>> PostgreSQL version: 9.2.1
>>> Operating system: Linux
>>> Description: =20
>>>=20
>>> select NULLIF('{1,2,3}'::integer[] - '{3,2,1}'::integer[], '{}'::integer=
[]);
>>> This returns an empty array. It should return NULL.=20
>>>=20
>>> Per RhodiumToad: the core code represents '{}' as an array with 0
>>> dimensions, whereas intarray represents it as an array with 1 dimension b=
ut
>>> 0 elements
>>>=20
>>> 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.
>>=20
>> I just got time to look at this, and it is certainly easier to see when
>> you use array_dims():
>>=20
>> SELECT '{1,2,3}'::integer[] - '{3,2,1}'::integer[];
>> ?column?
>> ----------
>> {}
>> =20
>> SELECT array_dims('{1,2,3}'::integer[] - '{3,2,1}'::integer[]);
>> array_dims
>> ------------
>> [1:0]
>> =20
>> SELECT array_dims('{}'::integer[]);
>> array_dims
>> ------------
>> (null)
>>=20
>> This is part of the larger TODO item of how to handle empty
>>> =3D1-dimensional empty arrays vs. zero-dimensional empty arrays, which i=
s
>> discussed here:
>>=20
>> https://wiki.postgresql.org/wiki/Todo#Arrays
>> Improve handling of empty arrays
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> SELECT array_dims('{1,2,3}'::integer[] - '{3,2,1}'::integer[]);
>> array_dims
>> ------------
>> (null)
>>=20
>> --=20
>> Bruce Momjian <bruce@momjian.us> http://momjian.us
>> EnterpriseDB http://enterprisedb.com
>>=20
>> + It's impossible for everything to be true. +
>=20
>> 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 =3D ARR_DATA_OFFSET(a) + sizeof(int) * num;
>> int i;
>>=20
>> + /* if no elements, return a zero-dimensional array */
>> + if (num =3D=3D 0)
>> + {
>> + ARR_NDIM(a) =3D 0;
>> + return a;
>> + }
>> +=20
>> if (num =3D=3D ARRNELEMS(a))
>> return a;
>=20
>>=20
>> --=20
>> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
>=20
>=20
> --=20
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>=20
> + It's impossible for everything to be true. +
>=20
В списке pgsql-bugs по дате отправления: