Re: right() returns the whole string for the most negative n

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: right() returns the whole string for the most negative n
Date: 2026-08-27 02:45:38
Message-ID: CAApHDvp+w04D2bXRqMgG1NrH+apGe6JAqiWHmzmCtXTKQK1ShQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 27 Aug 2026 at 14:27, Ewan Young <kdbase(dot)hack(at)gmail(dot)com> wrote:
> Rather than pile that cleanup onto this bug-fix thread, I'll send it as a
> separate follow-up so this fix can be considered on its own. Will post
> that shortly and CC you three.

Yes, another thread. Please also include a description of your method
for verifying the code matches for non-HAVE__BUILTIN_OP_OVERFLOW
builds.

Also, pg_neg_s32_overflow() was introduced in 2024 by 0a27c3d0f733,
which is v18+. Depending on Daniel's patience for backpatching two
different versions, it might be worth just using the == PG_INT32_MIN
method to fix the bug, then allowing the follow-up patch to switch
that in v20 only. That would mean v18 and v19 don't get the most
optimal fix, but it's hard to imagine that's going to be performance
critical.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Henson Choi 2026-08-27 03:01:16 Re: Row pattern recognition
Previous Message Ewan Young 2026-08-27 02:26:50 Re: right() returns the whole string for the most negative n