Re: [PATCH] Possible wrong result from inlining a STRICT SQL function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Possible wrong result from inlining a STRICT SQL function
Date: 2026-07-28 20:14:05
Message-ID: 260807.1785269645@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Looking closer at this one: just reinserting the old code for
ScalarArrayOpExpr isn't great. Assuming the SAOP is okay,
we'll fall through and call check_functions_in_node, which will
check the operator's strictness a second time. That doesn't
result in any wrong answer, but it wastes a syscache lookup.
I fixed that by converting the if-test series into an else-if
chain, which arguably it should have been from the beginning.
(Maybe the compiler can see that the if-conditions are mutually
exclusive, but why make it deduce that?)

Pushed with that correction.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-07-28 20:58:04 Re: hashjoins vs. Bloom filters (yet again)
Previous Message Sami Imseih 2026-07-28 20:05:03 Re: tablecmds: fix bug where index rebuild loses replica identity on partitions