aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvalidate.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-04-28 13:42:13 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-04-28 13:42:13 -0400
commit3752e3d210287787a881ae3c68da019aa86f414e (patch)
tree22fa7b894870126c083c2d6ab258694f77e26b7b /src/backend/access/gist/gistvalidate.c
parent52f44615cecf0c0038d79374423d4b5042f0a07c (diff)
downloadpostgresql-3752e3d210287787a881ae3c68da019aa86f414e.tar.gz
postgresql-3752e3d210287787a881ae3c68da019aa86f414e.zip
Detect more overflows in timestamp[tz]_pl_interval.
In commit 25cd2d640 I (tgl) opined that "The additions of the months and microseconds fields could also overflow, of course. However, I believe we need no additional checks there; the existing range checks should catch such cases". This is demonstrably wrong however for the microseconds field, and given that discovery it seems prudent to be paranoid about the months addition as well. Report and patch by Joseph Koshakow. As before, back-patch to all supported branches. (However, the test case doesn't work before v15 because we didn't allow wider-than-int32 numbers in interval literals. A variant test could probably be built that fits within that restriction, but it didn't seem worth the trouble.) Discussion: https://postgr.es/m/CAAvxfHf77sRHKoEzUw9_cMYSpbpNS2C+J_+8Dq4+0oi8iKopeA@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions