Skip site navigation (1) Skip section navigation (2)

Re: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)

From: "Valentine Gogichashvili" <valgog(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4613: intarray_del_elem returns an invalid empty array (for nullif comparison)
Date: 2009-01-14 11:18:03
Message-ID: 3ce9822f0901140318g31f479a2h70bbdccece2e7039@mail.gmail.com (view raw or flat)
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Valentine Gogichashvili" <valgog(at)gmail(dot)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
>

In response to

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2009-01-15 01:38:31
Subject: Re: BUG #4562: ts_headline() adds space when parsing url
Previous:From: Bruce MomjianDate: 2009-01-14 03:24:10
Subject: Re: BUG #4612: lc_numeric setting ignored

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group