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
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 |