Horton
Menu

Re: [PATCH] Fix hashed ScalarArrayOp semantics for NULL LHS with non-strict comparators

Chengpeng Yan <chengpeng_yan@outlook.com>

View thread
From: Chengpeng Yan <chengpeng_yan@outlook.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, cca5507 <cca5507@qq.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2026-04-23T05:47:01Z
Lists: pgsql-hackers 
> On Apr 23, 2026, at 13:32, David Rowley <dgrowleyml@gmail.com> wrote:
> 
> I thought of it, but didn't do it as it meant having to keep a bit
> more state to track if we've filled the cache yet, plus the extra
> costs incurred to check if we've done it yet that would have to be
> paid for every NULL lookup. We currently have to check if the hash
> table has been set up already, so I felt more comfortable installing
> the new code in with that.


That makes sense to me. I agree that tying it to the existing hash-table
setup is the simpler place to do it, and avoids adding extra state plus
another check on each NULL lookup.

So I am fine with keeping it as-is.
--
Best regards,
Chengpeng Yan

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix incorrect logic for hashed IN / NOT IN with non-strict operators