From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Wesley <richard@duckdblabs.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Nested comparison semantics are unpredictable
In-reply-to: <B8388D26-947E-482E-8359-325E54083969@duckdblabs.com>
References: <B8388D26-947E-482E-8359-325E54083969@duckdblabs.com>
Comments: In-reply-to Richard Wesley <richard@duckdblabs.com>
	message dated "Tue, 12 Aug 2025 09:16:22 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3409431.1755022342.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Aug 2025 14:12:22 -0400
Message-ID: <3409432.1755022342@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3409432.1755022342%40sss.pgh.pa.us>
Precedence: bulk

Richard Wesley <richard@duckdblabs.com> writes:
> I was trying to make our comparison semantics for nested types <https://=
github.com/duckdb/duckdb/issues/18039> match Postgres, and I found that th=
e semantics of comparisons change when a join is present.

It's not about joins.  It's about the syntactic form of the
expression.  When you write "ROW(...) =3D ROW(...)", that goes
through make_row_comparison_op(), which indeed behaves
differently from record_eq(), which is where the comparison
will end up when it looks like "var =3D var".  In particular
"ROW(x) =3D ROW(y)" is optimized into "x =3D y" which is why
you get a NULL for "row(0) =3D row(NULL)".  record_eq() is not
allowed to produce a null in such cases, though --- else it
would be unsuitable to use as a btree comparator.

There's a lot of historical baggage and spec-text-lawyering
behind all this, but the short answer is that we're unlikely
to change either behavior.

			regards, tom lane