Re: Tightening DecodeNumberField's parsing rules - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Tightening DecodeNumberField's parsing rules
Date
Msg-id CA+TgmoaFoY47AzyCYMF6eHrzZv+ZNUma5hCQHCVGJ+EAHv_7RA@mail.gmail.com
Whole thread Raw
In response to Tightening DecodeNumberField's parsing rules  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 27, 2025 at 2:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So what I propose we do about this is to apply the attached to HEAD
> and leave the back branches alone.

+1. In most cases, we pride ourselves on carefully validating the
input we receive and people on this list have been known to disparage
other products for failing to do the same. But our validation of
timestamps is notably less strict. I think that's somewhat unavoidable
given that there are multiple date-time formats that somebody might
use, but I'm in favor of not being more lax than we have to be. If
some input can't be interpreted as anything sensible, we should reject
it rather than making up a fake value. However, I agree that it's best
not to do such tightening in the back-branches.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Understanding when VM record needs snapshot conflict horizon
Next
From: Nathan Bossart
Date:
Subject: Re: Large expressions in indexes can't be stored (non-TOASTable)