]> granicus.if.org Git - postgresql/commit
Fix quoted-substring handling in format parsing for to_char/to_number/etc.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 18 Nov 2017 17:16:37 +0000 (12:16 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 18 Nov 2017 17:16:37 +0000 (12:16 -0500)
commit63ca86318dc3d6a768eed78efbc6ca014a0622a8
tree2bcd92f691ad3b524157f9d52eb37fb4133428e5
parent9288d62bb4b6f302bf13bb2fed3783b61385f315
Fix quoted-substring handling in format parsing for to_char/to_number/etc.

This code evidently intended to treat backslash as an escape character
within double-quoted substrings, but it was sufficiently confused that
cases like ..."foo\\"... did not work right: the second backslash
managed to quote the double-quote after it, despite being quoted itself.
Rewrite to get that right, while preserving the existing behavior
outside double-quoted substrings, which is that backslash isn't special
except in the combination \".

Comparing to Oracle, it seems that their version of to_char() for
timestamps allows literal alphanumerics only within double quotes, while
non-alphanumerics are allowed outside quotes; backslashes aren't special
anywhere; there is no way at all to emit a literal double quote.
(Bizarrely, their to_char() for numbers is different; it doesn't allow
literal text at all AFAICT.)  The fact that they don't treat backslash
as special justifies our existing behavior for backslash outside double
quotes.  I considered making backslash inside double quotes act the same
way (ie, special only if before "), which in a green field would be a
more consistent behavior.  But that would likely break more existing SQL
code than what this patch does.

Add some test cases illustrating this behavior.  (Only the last new
case actually changes behavior in this commit.)

Little of this behavior was documented, either, so fix that.

Discussion: https://postgr.es/m/3626.1510949486@sss.pgh.pa.us
doc/src/sgml/func.sgml
src/backend/utils/adt/formatting.c
src/test/regress/expected/numeric.out
src/test/regress/sql/numeric.sql