Re: BUG #6277: Money datatype conversion wrong with Russian locale - Mailing list pgsql-bugs

From Alexander Lakhin
Subject Re: BUG #6277: Money datatype conversion wrong with Russian locale
Date
Msg-id 4EACC8AF.2000708@gmail.com
Whole thread Raw
In response to Re: BUG #6277: Money datatype conversion wrong with Russian locale  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #6277: Money datatype conversion wrong with Russian locale  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@gmail.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #6277: Money datatype conversion wrong with Russian locale
Next
From: Tom Lane
Date:
Subject: Re: BUG #6277: Money datatype conversion wrong with Russian locale