On Fri, May 10, 2013 at 11:49:18AM -0400, Tom Lane wrote: > Patryk Kordylewski <p...@fooby.de> writes: > > SET lc_numeric TO 'de_DE.UTF-8'; > > SET > > > SELECT > > TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'), > > TO_NUMBER(TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'), > > 'FM99G999G999G999G999G999G999D000'); > > to_char | to_number > > -----------------+----------- > > 123.456.789,123 | 123.456 > > (1 row) > > I looked into this, and find that the reason it misbehaves is that > NUM_numpart_from_char() will treat a '.' as being a decimal point > *without any regard to locale considerations*. So even if we have > a locale-dependent format string and a locale that says '.' is a > thousands separator, it does the wrong thing. > > It's a bit surprising nobody's complained of this before. > > I propose the attached patch. I'm slightly worried though about whether > this might break any existing applications that are (incorrectly) > depending on a D format specifier being able to match '.' regardless of > locale. Perhaps we should only apply this to HEAD and not back-patch?
I never trust to_char() changes for backpatching. ;-) -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
