Re: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison) - Mailing list pgsql-bugs

From Valentine Gogichashvili
Subject Re: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)
Date
Msg-id 3ce9822f0901140318g31f479a2h70bbdccece2e7039@mail.gmail.com
Whole thread Raw
In response to Re: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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
>

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #4612: lc_numeric setting ignored
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #4562: ts_headline() adds space when parsing url