Re: Inconsistency between TO_CHAR() and TO_NUMBER() - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: Inconsistency between TO_CHAR() and TO_NUMBER()
Date
Msg-id 5190FF0E.4020602@vmware.com
Whole thread Raw
In response to Re: Inconsistency between TO_CHAR() and TO_NUMBER()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 13.05.2013 17:09, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas@vmware.com>  writes:
>> Would it be possible to be lenient, and also accept . as the decimal
>> separator, when there is no ambiguity? Ie. when . is not the thousands
>> separator.
>
> I originally coded it that way, but concluded that it was probably a
> waste of code space.  How many locales can you point to where neither
> the decimal point nor thousands_sep is "."?

On my laptop, there are eight locales that use "," as the decimal
separator and " " as the thousands separator.

$ grep -l "^thousands_sep.*U00A0" /usr/share/i18n/locales/* | xargs grep
-l "^decimal_point.*U002C"
/usr/share/i18n/locales/cs_CZ
/usr/share/i18n/locales/et_EE
/usr/share/i18n/locales/fi_FI
/usr/share/i18n/locales/lv_LV
/usr/share/i18n/locales/nb_NO
/usr/share/i18n/locales/ru_RU
/usr/share/i18n/locales/sk_SK
/usr/share/i18n/locales/uk_UA

Out of these, ru_RU actually uses "." as the LC_MONETARY decimal point,
even though it uses "," as the LC_NUMERIC decimal point. I think that
strengthens the argument for accepting both. I don't speak Russian, but
if you pass a monetary value to TO_NUMBER in ru_RU locale, using "." as
the decimal separator, you probably would expect it to work.

According to
http://en.wikipedia.org/wiki/Decimal_separator#Examples_of_use, many
countries accept either "1 234 567,89" or "1.234.567,89" style, but
looking at the locale files installed on my system, the latter style is
the one actually used (e.g Germany).

- Heikki

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #8154: pg_dump throws error beacause of field called "new".
Next
From: Willy-Bas Loos
Date:
Subject: Re: BUG #8154: pg_dump throws error beacause of field called "new".