From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: NULL in arrays |
Date: | 2004-01-15 15:29:52 |
Message-ID: | 22226.1074180592@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:
> dennis=# INSERT INTO foo VALUES (ARRAY[2,NULL]);
> INSERT 25353 1
> That last insert contains a NULL value which are not allowed in arrays and
> yet a insert is performed. The table contains a NULL value afterwards
> (and no array).
As we used to say at HP, this is not a bug, it's a definition
disagreement. You need to give a coherent argument why we should
change, not just claim it's wrong.
Given the present lack of support for null elements in arrays, it's
impossible to have any really pleasant behavior in cases like this.
But I don't see an inherent reason why "raise an error" is better than
"return a null array".
I think Joe Conway is planning to tackle that underlying misfeature
for 7.5. Whenever it happens, it will result in a number of behavioral
changes for arrays. I'm not eager to move the definition around in the
meantime, especially not in dot-releases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2004-01-15 15:57:48 | Re: BUG #1049: Invalid SQL Executed as JDBC Prepared Statement still executes embedded SQL |
Previous Message | Dennis Bjorklund | 2004-01-15 13:02:46 | Re: NULL in arrays |