Re: Test of value equivalency of row type, feature or bug?

On Thu, Dec 20, 2018 at 7:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?UTF-8?B?5a2Z5Yaw?= <subi(dot)the(dot)dream(dot)walker(at)gmail(dot)com> writes:
> > select t=t from (select 1, null) t;
>
> > If I manage to catch the documents, the result of the query should be null,
> > as an equivalency comparison of null-contained row-typed values is null.
> > Surprisingly, the query result turns out to be true.
>
> > Is this behavior a feature or a bug?
>
> It's a feature. The btree comparison functions (<, =, >, etc) for
> composite types have to provide a total order for their datatypes,
> and treating an individual null field as a reason to return null
> would break that.

That doesn't seem to be what is going on here nor is it immediately
obvious that such is what is documented.

https://www.postgresql.org/docs/11/functions-comparisons.html#ROW-WISE-COMPARISON

"""
The = and <> cases work slightly differently from the others. Two rows
are considered equal if all their corresponding members are non-null
and equal; the rows are unequal if any corresponding members are
non-null and unequal; otherwise the result of the row comparison is
unknown (null).
"""

I'm reading that as the OP did, which seems to contradict what you are saying.

Furthermore:

(9.6)
select (1,null::int)=(1,null::int) -- null
select t=t from (select (1, null::int)) t -- true

The t=t version must be true due to not caring what the contents of
"t" are, otherwise it would report null as the first example does...

David J.