Added to TODO:
Improve handling of NULLs in arrays
* http://archives.postgresql.org/pgsql-bugs/2008-11/msg9.php
---
Kevin Field wrote:
>
> The following bug has been logged online:
>
> Bu
Tom Lane wrote:
It's really all kind of messy ... we need to trade off simplicity of
definition, ease of use, backwards compatibility, and standards
compliance (though the standard has only 1-D arrays so it's of just
limited help here).
AFAICT, the standard would certainly allow a type specific
Kev <[EMAIL PROTECTED]> writes:
>> I'm loath to change just this one thing though. If we're going to
>> monkey with it, I think we should start by having a thought-through
>> proposal about the behavior of all the array functions for corner
>> cases like null arrays and empty arrays (cf recent dis
> I'm loath to change just this one thing though. If we're going to
> monkey with it, I think we should start by having a thought-through
> proposal about the behavior of all the array functions for corner
> cases like null arrays and empty arrays (cf recent discussion about
> zero-dimensional arr
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Kevin Field wrote:
>> select array_cat(null::integer[], '{3}'::integer[]);
>> ...doesn't return NULL, which it should, for consistency.
> Doesn't make sense to me either. I found that this was changed between
> 8.1 (where it returns null) and 8.2, b
Kevin Field wrote:
Section 9.2 in the docs say, 'The ordinary comparison operators yield null
(signifying "unknown") when either input is null.' This applies to other
operators too. For example, the result of tacking an unknown value onto a
known one is unknown, because you don't know what exac
The following bug has been logged online:
Bug reference: 4509
Logged by: Kevin Field
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Windows Server 2003 SP2
Description:array_cat's null behaviour is inconsistent
Details:
Section 9.2 in t
