Re: concatenation operator || with "null" array

From: "Brandon Aiken" <BAiken(at)winemantech(dot)com>
To: "stroncococcus" <stroncococcus(at)gmx(dot)de>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: concatenation operator || with "null" array
Date: 2006-12-08 20:05:00
Message-ID: F8E84F0F56445B4CB39E019EF67DACBA3C5495@exchsrvr.winemantech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

NULL concatenated to anything is NULL. Try this:

UPDATE test SET myint = COALESCE(myint || ARRAY[123], ARRAY[123]) WHERE
id = 1;

Or:

UPDATE test SET myint =
CASE WHEN myint IS NULL THEN ARRAY[123]
ELSE myint || ARRAY[123]
END
WHERE id = 1;

An empty array can be displayed as ARRAY[NULL], but defaults to type
TEXT. An explicit empty integer array would be ARRAY[NULL]::INTEGER[].
NULL arrays are not handled entirely consistently, though. Sometimes it
acts like a NULL, and sometimes it acts like a container of NULL.

--
Brandon Aiken
CS/IT Systems Engineer
-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org
[mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of stroncococcus
Sent: Wednesday, December 06, 2006 5:43 PM
To: pgsql-general(at)postgresql(dot)org
Subject: [GENERAL] concatenation operator || with "null" array

Hello!

When I try to fill an array with the concatenation operator, like
UPDATE test SET myint = myint || ARRAY[123] WHERE id = 1
that before that statement was null, then it is also null after that
statement.
But if there is already something in that array and I execute that
statement, then everything works fine and one can find the 123 there,
too.
Is this the normal behavior? Is there a way to "concatenate" to null
arrays as well, or do I have to test this inside my script, and if it
is null fill it normal for the first time?

Best regards,
Kai

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ben 2006-12-08 20:05:08 Re: Male/female
Previous Message Edoardo Panfili 2006-12-08 19:58:07 Re: strange (maybe) behaviour of table lock