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

=?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.

The whole question of when a composite value "is null" is messy.
It ought not be --- IMO, either you have a tuple or you don't ---
but the SQL committee did nobody any favors with their creative
specification for what "x IS [NOT] NULL" means for composite x.

Having said that, though, perhaps "t IS NOT NULL" would do what
you want here, since it's defined to be true only when each of
t's fields is not null.

regards, tom lane