aboutsummaryrefslogtreecommitdiff
path: root/src/common/file_utils.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-09-28 14:36:04 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-09-28 14:36:17 -0400
commitd3cd36a133d96ad5578b6c10279b55fd5b538093 (patch)
treeb75d2f6a40415325b2d6b45c369d8fb54d904b79 /src/common/file_utils.c
parent967ed9205bfcd89c1dde1e85735b32b404721399 (diff)
downloadpostgresql-d3cd36a133d96ad5578b6c10279b55fd5b538093.tar.gz
postgresql-d3cd36a133d96ad5578b6c10279b55fd5b538093.zip
Make to_timestamp() and to_date() range-check fields of their input.
Historically, something like to_date('2009-06-40','YYYY-MM-DD') would return '2009-07-10' because there was no prohibition on out-of-range month or day numbers. This has been widely panned, and it also turns out that Oracle throws an error in such cases. Since these functions are nominally Oracle-compatibility features, let's change that. There's no particular restriction on year (modulo the fact that the scanner may not believe that more than 4 digits are year digits, a matter to be addressed separately if at all). But we now check month, day, hour, minute, second, and fractional-second fields, as well as day-of-year and second-of-day fields if those are used. Currently, no checks are made on ISO-8601-style week numbers or day numbers; it's not very clear what the appropriate rules would be there, and they're probably so little used that it's not worth sweating over. Artur Zakirov, reviewed by Amul Sul, further adjustments by me Discussion: <1873520224.1784572.1465833145330.JavaMail.yahoo@mail.yahoo.com> See-Also: <57786490.9010201@wars-nicht.de>
Diffstat (limited to 'src/common/file_utils.c')
0 files changed, 0 insertions, 0 deletions