From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: inconsistent composite type null handling in plpgsql out variable |
Date: | 2009-08-31 17:26:59 |
Message-ID: | 162867790908311026v37ab529i1e7530229d060244@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
2009/8/31 Sam Mason <sam(at)samason(dot)me(dot)uk>:
> On Fri, Aug 28, 2009 at 02:06:02PM -0400, Merlin Moncure wrote:
>> 3) If we decide the sql standard is correct, so that (null, null) is
>> null == true, then we should observe rule 1 and make things work in
>> consistent way. This means, for example, that null::foo and (null,
>> null)::foo should not be distinct.
>
> 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
regards
Pavel Stehule
p.s. what isn't consistent (maybe - there are more possible interpretations) is
(NULL, NULL) IS DISTINCT FROM NULL is true
>
> I'd never noticed the ROW / RECORD dichotomy before; could one of these
> be made SQL compatible and the other use more sane semantics?
>
> --
> Sam http://samason.me.uk/
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2009-08-31 22:02:27 | lost statistics; analyze needs to execute twice |
Previous Message | Sam Mason | 2009-08-31 17:21:41 | Re: inconsistent composite type null handling in plpgsql out variable |