Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.12\))
Subject: Re: [PATCH] psql: Make ParseVariableDouble reject values above max
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <DF42FECA-1A0D-4CF7-AE64-8A438D2436E0@yesql.se>
Date: Mon, 18 May 2026 08:41:01 -0700
Cc: pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B2F64B1B-DC26-43A5-9238-16190DD5FD15@yesql.se>
References: 
 <CAMCrgp31p_5SDVi7dwnP39tTW5icQ0MWHA+N4kJdXgkL0PEy8w@mail.gmail.com>
 <DF42FECA-1A0D-4CF7-AE64-8A438D2436E0@yesql.se>
To: Sven Klemm <sven@tigerdata.com>
Archived-At: 
 <https://www.postgresql.org/message-id/B2F64B1B-DC26-43A5-9238-16190DD5FD15%40yesql.se>
Precedence: bulk

> On 9 May 2026, at 11:44, Daniel Gustafsson <daniel@yesql.se> wrote:
>=20
>> On 8 May 2026, at 17:39, Sven Klemm <sven@tigerdata.com> wrote:
>>=20
>> Hello,
>>=20
>>  ParseVariableDouble() in src/bin/psql/variables.c is asymmetric in =
how
>>  it handles the [min, max] bounds it documents. The lower-bound =
branch
>>  correctly returns false, but the upper-bound branch logs the error =
and
>>  then falls through to assign *result and return true. The function's
>>  contract ("the value must be within the range [min,max] in order to =
be
>>  considered valid"; "if unsuccessful, *result isn't clobbered") is
>>  broken on the upper-bound path.
>=20
> Indeed, that's a silly bug, not sure how I could have missed that.  We =
are
> currently in freeze for the upcoming minor releases but I have this =
staged to
> go in directly after.  Thanks for the report.

Pushed and backpatched to v18, with the addition of a test for this =
behaviour.

--
Daniel Gustafsson