Re: inconsistent composite type null handling in plpgsql out variable
От | Pavel Stehule |
---|---|
Тема | Re: inconsistent composite type null handling in plpgsql out variable |
Дата | |
Msg-id | 162867790908311026v37ab529i1e7530229d060244@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: inconsistent composite type null handling in plpgsql out variable (Sam Mason <sam@samason.me.uk>) |
Ответы |
Re: inconsistent composite type null handling in plpgsql out variable
|
Список | pgsql-bugs |
2009/8/31 Sam Mason <sam@samason.me.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 =3D=3D true, then we should observe rule 1 and make things work in >> consistent way. =C2=A0This 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? > > -- > =C2=A0Sam =C2=A0http://samason.me.uk/ > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs >
В списке pgsql-bugs по дате отправления: