From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: (record = record) inconsistent with record_eq(arg1, arg2) |
Date: | 2023-07-31 20:07:04 |
Message-ID: | 2947561.1690834024@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Monday, July 31, 2023, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>> select row(1,null::int) = (1,1::int); -- return null
>> select record_eq(row(1,null::int),(1,1::int)); --return false.
> This isn’t a bug though I can’t 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-WISE-COMPARISON
which documents the behavior of ROW(...) = ROW(...), and
https://www.postgresql.org/docs/current/functions-comparisons.html#COMPOSITE-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(...) = 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 =
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kong Man | 2023-07-31 23:00:48 | Re: pg_restore 14 skips ACL COLUMN when --schema is used |
Previous Message | Kong Man | 2023-07-31 19:50:21 | Re: pg_restore 14 skips ACL COLUMN when --schema is used |