On Tue, Oct 31, 2006 at 11:47:56PM -0500, Tom Lane wrote: > Because we depend on libc's locale support, which (on many platforms) > isn't designed to switch between locales cheaply. The fact that we > allow a per-database encoding spec at all was probably a bad idea in > hindsight --- it's out front of what the code can really deal with. > My recollection is that the Japanese contingent argued for it on the > grounds that they needed to deal with multiple encodings and didn't > care about encoding/locale mismatch because they were going to use > C locale anyway. For everybody else though, it's a gotcha waiting > to happen. Could this paragraph be put into the docs and/or the FAQ, please ? Along with the recommendation that if you require multiple encodings for your databases you better had your OS locale configured properly for UTF8 and use UNICODE databases or do initdb with the C-locale. > This stuff is certainly far from ideal, but the amount of work involved > to fix it is daunting; see many past pg-hackers discussions. Here are a few data points from my Debian/Testing system in favour of not worrying too much about installed ICU size as it is being used by other packages anyways: libicu36 Reverse Depends: openoffice.org-writer * OOo openoffice.org-filter-so52 openoffice.org-core libxerces27 * Xerces XML parser (Apache camp) libboost-regex1.33.1 libboost-dbg icu Reverse Depends: libicu36 libicu36 libxercesicu26 * Xerces, again libxercesicu25 libicu28-dev libicu28 libicu21c102 icu-i18ndata icu-data libwine * Wine This, of course, does not decrease the work required to get this going in PostgreSQL. Thanks for the great work, Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
