Обсуждение: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)

The following bug has been logged online:

Bug reference:      4613
Logged by:          Valentine Gogichashvili
Email address:      valgog@gmail.com
PostgreSQL version: 8.3.1
Operating system:   Debian Linux  (kernel 2.6.8)
Description:        intarray_del_elem returns an invalid empty array (for
nullif comparison)
Details:

I have checked the issue on the 8.2.1 and 8.3.1 by now.

When contrib/intarray module - operation (intarray_del_elem) returns an
empty array, is not supposed to be empty

testdb=# select

'{ -1 }'::integer[] - ( -1 ) as calculated_empty_int_array,

nullif( '{ -1 }'::integer[] - ( -1 ), '{}'::integer[]) as should_be_null,

nullif( '{}'::integer[], '{}'::integer[]) as
works_for_initially_empty_array,

nullif( '{ }'::integer[] - ( -1 ), '{}'::integer[]) as also_works;

 calculated_empty_int_array | should_be_null |
works_for_initially_empty_array | also_works
----------------------------+----------------+------------------------------
---+------------
 {}                         | {}             |
  |
(1 row)

So if we try to nullif an empty array, that was generated by the - operator
'{-1}'::integer[] - (-1), it does not see the array is empty.

With best regards,

-- Valentine Gogichashvili

"Valentine Gogichashvili" <valgog@gmail.com> writes:
> When contrib/intarray module - operation (intarray_del_elem) returns an
> empty array, is not supposed to be empty

This isn't really contrib/intarray's fault, it's a symptom of the
general question of what an "empty" array is.  See thread here:
http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php

Given the lack of consensus about how to change the behavior, I wouldn't
recommend holding your breath waiting for a fix --- and in any case
we'd not likely risk back-patching any such change.  Instead of testing
for equality to '{}' you'd probably be better off testing the array
dimensions, as suggested here:
http://archives.postgresql.org/pgsql-general/2008-10/msg00920.php

            regards, tom lane

Thanks for a rapid response,
Of course we are not waiting for the fix, and we had to use icount() call in
the PL/pgSQL code (array_upper(array, 1) also did work on the productive
system, returning 1 instead of 0, but I could not reproduce the issue with
any simple select statement). With nullif() call I could have kept
everything in the scope of the SQL statement, and stay in SLQ language,
without the need to use PL/pgSQL.

In the discussion of empty arrays I personally would go to the side of
Merlin Moncure with his '{{}, {}}' proposal.

I think, that the current approach goes in contradiction with the contract
for in and out functions. And the object that is represented as '{}' should
not have different behavior depending on the way, this object is created.

Anyway I can imagine, that as resize_intArrayType(ArrayType* a, int num) is
being used only by the functions working with one dimension integer arrays,
it could return a really empty array with construct_empty_array() if the num
is 0 instead of doing the resize as it is done now.

With best regards,

-- Valentine Gogichashvili


On Tue, Jan 13, 2009 at 7:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Valentine Gogichashvili" <valgog@gmail.com> writes:
> > When contrib/intarray module - operation (intarray_del_elem) returns an
> > empty array, is not supposed to be empty
>
> This isn't really contrib/intarray's fault, it's a symptom of the
> general question of what an "empty" array is.  See thread here:
> http://archives.postgresql.org/pgsql-hackers/2008-10/msg01033.php
>
> Given the lack of consensus about how to change the behavior, I wouldn't
> recommend holding your breath waiting for a fix --- and in any case
> we'd not likely risk back-patching any such change.  Instead of testing
> for equality to '{}' you'd probably be better off testing the array
> dimensions, as suggested here:
> http://archives.postgresql.org/pgsql-general/2008-10/msg00920.php
>
>                        regards, tom lane
>