aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2023-02-20 16:55:59 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2023-02-20 16:55:59 -0500
commitf0d0394e84ceeda6f22eb3fdb89bd8adbfc13985 (patch)
treee3c64cb5798c3b920aff3ba6885bf54a63ff6bea /src/backend/executor/nodeModifyTable.c
parentf6db76c55509a60cc8c22ced56ff9322ee6f1742 (diff)
downloadpostgresql-f0d0394e84ceeda6f22eb3fdb89bd8adbfc13985.tar.gz
postgresql-f0d0394e84ceeda6f22eb3fdb89bd8adbfc13985.zip
Fix parsing of ISO-8601 interval fields with exponential notation.
Historically we've accepted interval input like 'P.1e10D'. This is probably an accident of having used strtod() to do the parsing, rather than something anyone intended, but it's been that way for a long time. Commit e39f99046 broke this by trying to parse the integer and fractional parts separately, without accounting for the possibility of an exponent. In principle that coding allowed for precise conversions of field values wider than 15 decimal digits, but that does not seem like a goal worth sweating bullets for. So, rather than trying to manage an exponent on top of the existing complexity, let's just revert to the previous coding that used strtod() by itself. We can still improve on the old code to the extent of allowing the value to range up to 1.0e15 rather than only INT_MAX. (Allowing more than that risks creating problems due to precision loss: the converted fractional part might have absolute value more than 1. Perhaps that could be dealt with in some way, but it really does not seem worth additional effort.) Per bug #17795 from Alexander Lakhin. Back-patch to v15 where the faulty code came in. Discussion: https://postgr.es/m/17795-748d6db3ed95d313@postgresql.org
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions