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

Re: [GENERAL] trouble with to_char('L')

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [GENERAL] trouble with to_char('L')
Date: 2009-05-29 18:16:26
Message-ID: 21710.1243620986@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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()
>> 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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-05-29 18:23:29
Subject: Re: Clean shutdown and warm standby
Previous:From: Bruce MomjianDate: 2009-05-29 18:16:19
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type

pgsql-general by date

Next:From: Kris JurkaDate: 2009-05-29 18:24:21
Subject: Re: Pl/java in 8.4 bet1 sources compilation failed
Previous:From: Scott BaileyDate: 2009-05-29 17:53:51
Subject: Re: composite type and domain

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