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
Date: Tue, 12 Aug 2025 14:12:22 -0400
Message-ID: <3409432.1755022342@sss.pgh.pa.us> (raw)
In-Reply-To: <B8388D26-947E-482E-8359-325E54083969@duckdblabs.com>
References: <B8388D26-947E-482E-8359-325E54083969@duckdblabs.com>
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 the 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(...) = 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 = var". In particular
"ROW(x) = ROW(y)" is optimized into "x = y" which is why
you get a NULL for "row(0) = 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, richard@duckdblabs.com, pgsql-bugs@lists.postgresql.org
Subject: Re: Nested comparison semantics are unpredictable
In-Reply-To: <3409432.1755022342@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox