]> granicus.if.org Git - postgresql/commit
Prevent to_number() from losing data when template doesn't match exactly.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 17 Nov 2017 17:04:06 +0000 (12:04 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 17 Nov 2017 17:04:13 +0000 (12:04 -0500)
commite87d4965bd39e4d0d56346c1bbe9361d3eb9ff0a
tree8acb90033814666bc1199b7dd731bfcb6a9cd849
parentbe92769e4e63de949fe3ba29e0bf5c0a96f54ae3
Prevent to_number() from losing data when template doesn't match exactly.

Non-data template patterns would consume characters whether or not those
characters were what the pattern expected, for example
SELECT TO_NUMBER('1234', '9,999');
produced 134 because the '2' got eaten by the comma pattern.  This seems
undesirable, not least because it doesn't happen in Oracle.  For the ','
and 'G' template patterns, we can fix this by consuming characters only
if they match what the pattern would output.  For non-data patterns such
as 'L' and 'TH', it seems impractical to tighten things up to the point of
consuming only exact matches to what the pattern would output; but we can
improve matters quite a lot by redefining the behavior as "consume only
characters that aren't digits, signs, decimal point, or comma".

Also, fix it so that the behavior is to consume the number of *characters*
the pattern would output, not the number of *bytes*.  The old coding would
do surprising things with non-ASCII currency symbols, for example.  (It
would be good to apply that rule for literal text as well, but this commit
only fixes it for non-data patterns.)

Oliver Ford, reviewed by Thomas Munro and Nathan Wagner, and whacked around
a bit more by me

Discussion: https://postgr.es/m/CAGMVOdvpbMqPf9XWNzOwBpzJfErkydr_fEGhmuDGa015z97mwg@mail.gmail.com
doc/src/sgml/func.sgml
src/backend/utils/adt/formatting.c
src/test/regress/expected/numeric.out
src/test/regress/sql/numeric.sql