9.3: Empty arrays returned by array_remove()
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.
I don't think it's intentional, but the current code in array_remove()
can return something like this:
SELECT array_dims(array_remove(array[1], 1));
array_dims
------------
[1:0]
(1 row)
and so the resulting empty 1-d array won't compare as equal to the
usual 0-d empty array:
SELECT array_remove(array[1], 1) = '{}';
?column?
----------
f
(1 row)
The LHS is effectively '[1:0]={}', but we don't currently allow that
syntax, so I don't think we should be returning it (it wouldn't
survive a dump/restore, for example).
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 31 May 2013 02:52, Dean Rasheed <dean.a.rasheed@gmail.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.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 31 May 2013 08:34, Brendan Jurd <direvus@gmail.com> wrote:
On 31 May 2013 02:52, Dean Rasheed <dean.a.rasheed@gmail.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.
Regards,
Dean
Attachments:
array_remove.patchapplication/octet-stream; name=array_remove.patchDownload
diff --git a/src/backend/utils/adt/arrayfuncs.c b/src/backend/utils/adt/arrayfuncs.c
new file mode 100644
index f53a0d2..c2dc1fb
*** a/src/backend/utils/adt/arrayfuncs.c
--- b/src/backend/utils/adt/arrayfuncs.c
*************** array_replace_internal(ArrayType *array,
*** 5398,5403 ****
--- 5398,5411 ----
return array;
}
+ /* If all elements were removed return an empty array */
+ if (nresult == 0)
+ {
+ pfree(values);
+ pfree(nulls);
+ return construct_empty_array(element_type);
+ }
+
/* Allocate and initialize the result array */
if (hasnulls)
{
diff --git a/src/test/regress/expected/arrays.out b/src/test/regress/expected/arrays.out
new file mode 100644
index 051bac9..4ac1e08
*** a/src/test/regress/expected/arrays.out
--- b/src/test/regress/expected/arrays.out
*************** select array_remove(array['A','CC','D','
*** 1568,1573 ****
--- 1568,1579 ----
select array_remove('{{1,2,2},{1,4,3}}', 2); -- not allowed
ERROR: removing elements from multidimensional arrays is not supported
+ select array_remove(array['X','X','X'], 'X') = '{}';
+ ?column?
+ ----------
+ t
+ (1 row)
+
select array_replace(array[1,2,5,4],5,3);
array_replace
---------------
diff --git a/src/test/regress/sql/arrays.sql b/src/test/regress/sql/arrays.sql
new file mode 100644
index 04e9725..6dce0dc
*** a/src/test/regress/sql/arrays.sql
--- b/src/test/regress/sql/arrays.sql
*************** select array_remove(array[1,2,2,3], 5);
*** 437,442 ****
--- 437,443 ----
select array_remove(array[1,NULL,NULL,3], NULL);
select array_remove(array['A','CC','D','C','RR'], 'RR');
select array_remove('{{1,2,2},{1,4,3}}', 2); -- not allowed
+ select array_remove(array['X','X','X'], 'X') = '{}';
select array_replace(array[1,2,5,4],5,3);
select array_replace(array[1,2,5,4],5,NULL);
select array_replace(array[1,2,NULL,4,NULL],NULL,5);
On Fri, May 31, 2013 at 08:55:49AM +0100, Dean Rasheed wrote:
On 31 May 2013 08:34, Brendan Jurd <direvus@gmail.com> wrote:
On 31 May 2013 02:52, Dean Rasheed <dean.a.rasheed@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers