Re: [PATCH] Fix hashed ScalarArrayOp semantics for NULL LHS with non-strict comparators
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Chengpeng Yan <chengpeng_yan@outlook.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-04-20T04:14:03Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > I've attached a version that "probes" the equality function for its > NULL = NULL behaviour and its NULL = non-NULL behaviour and returns > whatever the result of the probe was at the appropriate time. > What I came up with does feel quite elaborate, so I'd quite like a 2nd opinion. > The patch does assume that the non-strict function will return the > same thing for NULL = non-NULL as it will for non-NULL = NULL. Meh. I think we assume that hashable equality functions satisfy the symmetric law, ie A = B if and only if B = A, so that part is fine. However, I do not care for the assumption that any random non-null input will produce the same answer. As a quick counter-example, consider a text-like datatype that tries to emulate Oracle's semantics that an empty string is the same as NULL. Your code would arrive at different results depending on whether the first non-null input chanced to be an empty string. (I've not read this whole thread, so I don't have a global opinion on what we ought to do here. I suspect it's a tricky subject.) regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix incorrect logic for hashed IN / NOT IN with non-strict operators
- 109de35b705c 14.23 landed
- 622f8b53014e 15.18 landed
- a2a0060d5d8f 16.14 landed
- 3fda3e12f41b 17.10 landed
- 035c520db866 18.4 landed
- 94219a73f79d 19 (unreleased) landed