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

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Thu, Dec 20, 2018 at 7:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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

That's talking specifically about the results of a comparison of
two row constructors, ie "ROW(...) = ROW(...)".

The fact that this acts differently from other seemingly-related cases
can be blamed directly on the SQL spec.

regards, tom lane