Priem, Alexander said: > Would lc-collate=C be bad in combination with UNICODE encoding? What > lc-collate setting would you recommend for UNICODE encoding which will > provide good sorting for all (most) common languages? (dutch, english, > french, german) It seems that LC_COLLATE=C is not a good idea when using UTF-8... On my db server, /etc/sysconfig/i18n contains LANG="en_GB.UTF-8" SUPPORTED="en_GB.UTF-8:en_GB:en:en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16" and locale -a produces C [..snip..] en_GB en_GB.iso885915 en_GB.utf8 [..snip..] en_US en_US.iso885915 en_US.utf8 [..snip..] POSIX and locale produces locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= QUESTION: Because I want UNICODE encoding/support in postgres, does that mean that when I init my db I should specify (for en_GB support) initdb -E UNICODE <-- (NO LOCALE, default to en_GB) or initdb --locale=en_GB -E UNICODE or should I use initdb --locale=en_GB.utf8 -E UNICODE Basically I want the database to be able to support all character encodings, and to sort according to the en_GB locale. The monetary and date formats determined by the locale are irrelevant for us, as we return correctly localised versions of this data from our web app (which is connected to postgres) based on the user's selected language for their current web browser session. Thanks to anyone who can answer the initdb question above, hopefully the answer will help others too. John Sidney-Woollett ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
