Tom Lane wrote: > Hiroshi Inoue <in...@tpf.co.jp> writes: >> Tom Lane wrote: >>> I think what this suggests is that there probably needs to be some >>> encoding conversion logic near the places we examine localeconv() >>> output. > >> Attached is a patch to the current CVS. >> It uses a similar way like LC_TIME stuff does. > > I'm not really in a position to test/commit this, since I don't have a > Windows machine. However, since no one else is stepping up to deal with > it, here's a quick review:
Thanks for the review. I've forgotten the patch because Japanese doesn't have trouble with this issue (the currency symbol is ascii \). If this is really expected to be fixed, I would update the patch according to your suggestion. > * This seems to be assuming that the user has set LC_MONETARY and > LC_NUMERIC the same. What if they're different? Strictky speaking they should be handled individually. > * What if the selected locale corresponds to Unicode (ie UTF16) > encoding? As far as I tested set_locale(LC_MONETARY, xxx.65001) causes an error. > * #define'ing strdup() to do something rather different from strdup > seems pretty horrid from the standpoint of code readability and > maintainability, especially with nary a comment explaining it. Maybe using a function instead of strdup() which calls dbstr_win32() in case of Windows would be better. BTW grouping and money_grouping seem to be out of encoding conversion. Are they guaranteed to be null terminated? > * Code will dump core on malloc failure. I can take care of it. > * Since this code is surely not performance critical, I wouldn't bother > with trying to optimize it; hence drop the special case for all-ASCII. I can take care of it. > > * Surely we already have a symbol somewhere that can be used in > place of this: > #define MAX_BYTES_PER_CHARACTER 4 I can't find it. max(pg_encoding_max_length(encoding), pg_encoding_max_length(PG_UTF8)) may be better. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers