Hiroshi Inoue <inoue(at)tpf(dot)co(dot)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()
> 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)
* #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
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2009-05-29 18:23:29|
|Subject: Re: Clean shutdown and warm standby|
|Previous:||From: Bruce Momjian||Date: 2009-05-29 18:16:19|
|Subject: Re: pg_migrator and an 8.3-compatible tsvector data
pgsql-general by date
|Next:||From: Kris Jurka||Date: 2009-05-29 18:24:21|
|Subject: Re: Pl/java in 8.4 bet1 sources compilation failed|
|Previous:||From: Scott Bailey||Date: 2009-05-29 17:53:51|
|Subject: Re: composite type and domain|