From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | jian he <jian(dot)universality(at)gmail(dot)com> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | (record = record) inconsistent with record_eq(arg1, arg2) |
Date: | 2023-07-31 14:52:09 |
Message-ID: | CAKFQuwYEw-f6RSP0xzUNNMus=OcyGX-6GSOPorb3YtRPPEiyxg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Monday, July 31, 2023, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> hi.
> pg15: https://dbfiddle.uk/3_GxPdj4
> not sure if it's a bug or I misunderstood.
>
> 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.
The SQL standard mandates the query behavior of the equals operator while
internal indexing and hash details require that the equality function not
return null.
Calling record_eq directly in SQL is unsupported so the claim that the
second query is buggy is incorrect altogether. We don’t promise any
particular result to the user in that situation, and could indeed remove
the function and the query could produce an error and we’d be technically
bug-free.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Kong Man | 2023-07-31 19:50:21 | Re: pg_restore 14 skips ACL COLUMN when --schema is used |
Previous Message | jian he | 2023-07-31 13:45:24 | (record = record) inconsistent with record_eq(arg1, arg2) |