Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group