Re: Inconsistency between TO_CHAR() and TO_NUMBER()

Patryk Kordylewski <pk(at)fooby(dot)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?

regards, tom lane