From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: jian he <jian.universality@gmail.com>,
        "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Re: (record = record) inconsistent with record_eq(arg1, arg2)
In-reply-to: 
 <CAKFQuwYEw-f6RSP0xzUNNMus=OcyGX-6GSOPorb3YtRPPEiyxg@mail.gmail.com>
References: 
 <CACJufxF6T4-vOqg1eu_JGrXszTUaHUmmjzCQUcuF6W56dhS+Vw@mail.gmail.com>
 <CAKFQuwYEw-f6RSP0xzUNNMus=OcyGX-6GSOPorb3YtRPPEiyxg@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Mon, 31 Jul 2023 07:52:09 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2947560.1690834024.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 31 Jul 2023 16:07:04 -0400
Message-ID: <2947561.1690834024@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2947561.1690834024%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, July 31, 2023, jian he <jian.universality@gmail.com> wrote:
>> select row(1,null::int) =3D (1,1::int); -- return null
>> select record_eq(row(1,null::int),(1,1::int)); --return false.

> This isn=E2=80=99t a bug though I can=E2=80=99t point to the exact code =
where the
> difference manifests.

Yeah, the difference in behavior is deliberate.  See

https://www.postgresql.org/docs/current/functions-comparisons.html#ROW-WIS=
E-COMPARISON

which documents the behavior of ROW(...) =3D ROW(...), and

https://www.postgresql.org/docs/current/functions-comparisons.html#COMPOSI=
TE-TYPE-COMPARISON

which documents the behavior of record comparisons that are written
in other ways, and explains the reason for the difference.  The
SQL standard governs the behavior of "ROW(...) =3D ROW(...)", but last
I looked they don't really have a notion of composite-valued scalars,
so the spec has nothing to say about what "row-valued-expression =3D
row-valued-expression" should do.  Even if it did, we would not
change this, because it's too important to have a total ordering
for composite columns.

			regards, tom lane