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 <t...@sss.pgh.pa.us> wrote:
> "Valentine Gogichashvili" <val...@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
>
