From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: inconsistent composite type null handling in plpgsql out variable |
Date: | 2009-09-01 09:35:09 |
Message-ID: | 20090901093509.GI5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
> 2009/8/31 Sam Mason <sam(at)samason(dot)me(dot)uk>:
> > The more awkward case (to me anyway) is that the standard says (1,NULL)
> > IS NULL should evaluate to TRUE.
>
> what?
>
> only (NULL, NULL) IS NULL is true
Bah, sorry you're right! I was rattling my favorite tin and getting
mixed up with the behavior with IS NOT NULL, the negation of which
would say this row is null. I.e:
SELECT NOT (1,NULL) IS NOT NULL;
evaluates to TRUE. I think the consensus is that we should continue to
follow the spec on this, but I was getting confused as to which operator
contains the EXISTS and FORALL operator. I.e. a value "v" IS NULL iff
all elements of "v" are not 'the null value', whereas "v" IS NOT NULL
iff an element of "v" is 'the null value'.
> p.s. what isn't consistent (maybe - there are more possible
> interpretations) is
>
> (NULL, NULL) IS DISTINCT FROM NULL is true
Yup, I'd agree with Merlin that a ROW consisting entirely of 'null
values' should itself be 'the null value' (to use the terminology from
the copy of the SQL spec I'm reading). I think this should also work
recursively:
SELECT ROW(ROW(NULL)) IS DISTINCT FROM NULL;
should return FALSE, in my understanding.
--
Sam http://samason.me.uk/
From | Date | Subject | |
---|---|---|---|
Next Message | Hitoshi Harada | 2009-09-01 10:48:47 | Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4. |
Previous Message | Heikki Linnakangas | 2009-09-01 08:11:26 | Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4. |