Re: Inconsistency between TO_CHAR() and TO_NUMBER()

On 13.05.2013 17:09, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas(at)vmware(dot)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