Why would you? UTF-16 and UTF-8 are just different representations for the same domain of characters. On Fri, 22 Apr 2005, Ale Raza wrote: > Are we not going to lose some characters if we are putting a UTF-16 to UTF-8 > translation in front of libpq? > > Ale. > > -----Original Message----- > From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] > Sent: Friday, April 22, 2005 12:14 PM > To: Bruce Momjian > Cc: Ale Raza; pgsql-general@xxxxxxxxxxxxxx > Subject: Re: libpq Unicode support? > > > Bruce Momjian <pgman@xxxxxxxxxxxxxxxx> writes: > > Tom Lane wrote: > >> Oh? Who's working on it, or even interested? Was there discussion > >> of adding it to TODO? > > > TODO has: > > > o Add support for Unicode > > > To fix this, the data needs to be converted to/from UTF16/UTF8 > > so the Win32 wcscoll() can be used, and perhaps other functions > > like towupper(). However, UTF8 already works with normal > > locales but provides no ordering or character set classes. > > That's completely unrelated --- it's talking about making correct use of > Windows' locale support in one small bit inside the server. > > To make libpq UTF-16 capable, we'd have to change its API for all > strings; either make the strings counted rather than null-terminated, > or make the string elements wchar instead of char. After that we'd > have to hack the FE/BE protocol too (or more likely, require libpq > to translate UTF-16 to UTF-8 before sending to the server). I don't > foresee anyone doing any of this, at least not in the near term. > > Putting a UTF-16 to UTF-8 translation in front of libpq seems a lot > more practical. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
