Re: BUG #19602: Vuln46: citext split_part silently returns NULL for a zero field position instead of raising core sp

Hi Aleksander and Jaehyuck,

On Tue, Nov 10, 2026 at 4:42 PM Aleksander Alekseev
<aleksander(at)tigerdata(dot)com> wrote:
> Without WHEN .. ELSE and COALESCE it should be faster too.

It is, and it is also more exact, so v2 uses your version; thanks. My
20000-case check for v1 used lower case only. On 300000 random ASCII
cases with mixed case and regex metacharacters and 70 directed ones,
both bodies match an exact reference. The only differences I found
are on U+01C5, U+01C8, U+01CB and U+01F2, which ~* does not match
against themselves; v1 misses them as delimiters, v2 does not. v2 is
attached.

On Wed, Nov 11, 2026 at 10:22 AM Jaehyuck Sa
<jaehyuck(dot)sa(dot)dev(at)gmail(dot)com> wrote:
> split_part(v, ',', 2) over 200000 rows went from about 80 ms to
> 250 ms. Is that acceptable?

v2 is inlined again. On 200000 rows like that, v1 takes 593 ms, 1.8
208 ms and v2 184 ms (release build, versions alternated, median of
30 runs); 1.8 is not a fair baseline, as it gets negative positions
wrong. At 5000 characters per row v1 and v2 differ by about 2%.

> split_part() is IMMUTABLE, so expression indexes and stored generated
> columns built under 1.8 keep the old results, e.g. NULL where the
> position is negative or past the last field.

It reproduces with both bodies (index scan 0 rows, seq scan 1, until
REINDEX), and so do partition keys. v2's commit message lists these,
and that a stored position of zero now makes REINDEX fail.

> Is this meant for master only? Branches before 18 have citext 1.6.

Yes, master only: 14 to 17 have the same bug in the old body, but the
1.8--1.9 script only fits where 1.8 is installed, 18 and master.

Regards,
Manu