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: * This seems to be assuming that the user has set LC_MONETARY and LC_NUMERIC the same. What if they're different? * What if the selected locale corresponds to Unicode (ie UTF16) encoding? * #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. * Code will dump core on malloc failure. * 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. * Surely we already have a symbol somewhere that can be used in place of this: #define MAX_BYTES_PER_CHARACTER 4 regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers