Re: BUG #6277: Money datatype conversion wrong with Russian locale

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6277: Money datatype conversion wrong with Russian locale
Date: 2011-10-30 03:46:55
Message-ID: 4EACC8AF.2000708@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I think there is no need to leave such assumptions. I would propose the
following fix: http://pastebin.com/EBw5YB65 (it corrects a BUG #6144 too)
I can send it as a patch if you wish. Please notice a comments regarding
regression tests. IMHO at least currency symbol separator should be
processed as specified in lconv. And maybe mon_decimal_point,
currency_symbol and negative_sign should be allowed to be empty too if
it's defined by a locale.

Best regards,
Alexander

29.10.2011 20:17, Tom Lane writes:
> "Alexander LAW"<exclusion(at)gmail(dot)com> writes:
>> It's caused by wrong mon_thousands_sep processing in
>> backend/utils/adt/cash.c, cash_out function.
>> The code assumes that the thousands separator fits in one character. But in
>> Russian locale we have non-breakable space as the thousands separator (0xC2
>> 0xA0 in UTF-8).
> Hmm ... looks like cash_out really needs a significant rewrite to make
> that work nicely. It's combining counting of digit positions with
> counting of output bytes, which was messy enough already, but gets
> worse fast if the thousands separator isn't a single byte.
>
> Does anyone know of locales where the decimal point isn't a single byte?
> I'm wondering if that assumption needs to be got rid of too.
>
> regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2011-10-30 14:58:53 Re: [v9.2] make_greater_string() does not return a string in some cases
Previous Message Robert Haas 2011-10-30 00:04:09 Re: [v9.2] make_greater_string() does not return a string in some cases