[BUGS] BUG #6277: Money datatype conversion wrong with Russian locale
The following bug has been logged online: Bug reference: 6277 Logged by: Alexander LAW Email address: exclus...@gmail.com PostgreSQL version: 9.1.1 Operating system: Windows Description:Money datatype conversion wrong with Russian locale Details: When lc_monetary is set to Russian, money values having 4+ digits formatted incorrectly. E.g. following select: set lc_monetary='Russian'; select '1000'::money; returns a string that can't be displayed. 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). The cash_out function uses only the first char (0xC2) of it and thus returns an invalid string: 1\xC2000. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6277: Money datatype conversion wrong with Russian locale
"Alexander LAW" 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6277: Money datatype conversion wrong with Russian locale
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" 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
