=========== 1999 Jul 21 =========== Josef Balatka, asked us not to remove RECODE and sent me Czech ISO-8859-2 -> WIN-1250 translation table. RECODE is no longer contains just Cyrillic RECODE and will stay in PostgreSQL. He also created some bits of documentation, mostly concerning RECODE - see README.Charsets. =========== 1999 Apr 14 =========== Tatsuo Ishii updated Multibyte support extending it to Cyrillic language. Now PostgreSQL supports KOI8-R, WIN-1251, ISO8859-5 and CP866 (ALT) encodings. Short instruction on using this feature follows. Longer discussion of Multibyte support is in README.mb. WARNING! Now with Multibyte support Cyrillic RECODE declared obsolete and will be removed from Postgres. If you are using RECODE consider switching to Multibyte support. Instructions on how to prepare Postgres for Cyrillic Multibyte support. ---------------------------------------------------------------------- First, you need to backup all your databases. I recommend to backup the entire Postgres directory, including binaries and libraries - thus you can easily restore if something goes wrong. Dump you data: pg_dumpall > dump.db Stop postmaster. Configure, compile and install Postgres. (I'll mostly talk about KOI8-R encoding, this is just to make examples a little more clear; you can use any supported encoding.) cd src ./configure --enable-locale --with-mb=KOI8 make make install Make sure you've backed up your databases. Doublecheck your backup. I really mean it - make regular backups and test your backups sometimes by fake restore. Remove your data directory (better, rename or move it). Run initdb saying your primary encoding: initdb -e KOI8. If you omit encoding, primary encoding from configure will be taken. Start postmaster. Create databases: createdb -e KOI8. Again, you can omit encoding - default encoding will be used. You are not forced to use the same encoding for all your databases - you can create different databases with different encodings. Load your data from the dump you've created: psql < dump.db That's all! Now you are ready to enjoy the full power of Multibyte support. To use Multibyte support you do not need to do something special - just execute your queries. If client program does not set encoding, it will get the data in database encoding. But client may ask Postgres to do automatic server-to-client and client-to-server conversions. There are 2 (two) ways client program declares its encoding: 1) client explicitly executes the query SET CLIENT_ENCODING TO 'win'; 2) client started with environment variable set. Examples - using sh syntax: PGCLIENTENCODING='win'; export PGCLIENTENCODING using csh syntax: setenv PGCLIENTENCODING 'win' Setting PGCLIENTENCODING even if you use same client encding as the database would omit an overhead of asking the database encoding while initiating the connection, so it is good idea to set it in any case. Now you may run test suite and see Multibyte support in action. Go to .../src/test/locale and run make clean all test-koi2win =========== 1998 Nov 20 =========== I extended locale support, originally written by Oleg Bartunov . Now ORDER BY (if PostgreSQL configured with --enable-locale) uses strcoll() for all text fields: char(n), varchar(n), text. I included test suite .../src/test/locale. I didn't include this in the regression test because not so much people require locale support. Read .../src/test/locale/README for details on the test suite. Many thanks to Oleg Bartunov (oleg@sai.msu.su) and Thomas G. Lockhart (lockhart@alumni.caltech.edu) for hints, tips, help and discussion. Oleg.