Fix portability issues in datetime parsing.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 3 Apr 2022 21:04:21 +0000 (17:04 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 3 Apr 2022 21:04:33 +0000 (17:04 -0400)
commit591e088dd5b357796e136c13dfcdb1f06fd7a3c2
tree7fb2dd81ceece5c68645bb7e112b4f6ac224ebf2
parentf3c15cbe5065f8c4fb902af8f810a8061a802417
Fix portability issues in datetime parsing.

datetime.c's parsing logic has assumed that strtod() will accept
a string that looks like ".", which it does in glibc, but not on
some less-common platforms such as AIX.  The result of this was
that datetime fields like "123." would be accepted on some platforms
but not others; which is a sufficiently odd case that it's not that
surprising we've heard no field complaints.  But commit e39f99046
extended that assumption to new places, and happened to add a test
case that exposed the platform dependency.  Remove this dependency
by special-casing situations without any digits after the decimal
point.

(Again, this is in part a pre-existing bug but I don't feel a
compulsion to back-patch.)

Also, rearrange e39f99046's changes in formatting.c to avoid a
Coverity complaint that we were copying an uninitialized field.

Discussion: https://postgr.es/m/1592893.1648969747@sss.pgh.pa.us
src/backend/utils/adt/datetime.c
src/backend/utils/adt/formatting.c
src/test/regress/expected/interval.out
src/test/regress/sql/interval.sql