Обсуждение: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)
BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)
От
"Valentine Gogichashvili"
Дата:
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
Re: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)
От
"Valentine Gogichashvili"
Дата:
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 >