Re: encoding names v2.

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: encoding names v2.
Date: 2001-09-07 20:13:32
Message-ID: 200109072013.f87KDWR21192@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


Tatsuo has applied this. Thanks.

>
> Hi,
>
> all are almost same as in last version of this patch. Here are new
> changes:
>
> - aliases cyrillic, cp819, ibm819, isoir100x, l1-4 are removed
> - KOI8 is KOI8-R in *all* functions, maps, etc.
> - WIN is window-1251 (WIN1251) --- // ---
> - ALT is ALT :-)
> - UNICODE is utf-8
> - PG_ prefix is used for all SQL_ASCII and the others
> - fixed bug with --enable-unicode-conversion
>
> - getdatabaseencoding() is compatible with old versions, but
> in the code is commented as deprecated.
>
> - getdbencoding() is new function that return correct encoding names
>
> test2=# select getdatabaseencoding(), getdbencoding();
> getdatabaseencoding | getdbencoding
> ---------------------+---------------
> LATIN2 | ISO-8859-2
> (1 row)
>
> - pg_encoding_to_char() and other routines return new names! Only
> for getdatabaseencoding() we keep back compatibility - needful for
> JDBC.
>
> - all encoding names use '-'. I hope we will never see a problem with
> it and some operator. Encoding names must be used as quoted string.
>
> Only for SQL_ASCII is used '_', because I see that JDBC has hardcoded
> "pg_encoding_to_char(1) = 'SQL_ASCII'" :-(((
>
> - the ./configure.in:
> * use new encoding names too for --enable-multibyte
> * define MULTIBYTE that handle default encoding id
> * define MULTIBYTE_NAME that handle default encoding name (neeful
> for initdb)
>
> Note: old code use same names for macros and for encoding names, but
> now it's in Makefile.global:
>
> MULTIBYTE = PG_KOI8R /* id */
> MULTIBYTE_NAME = "KOI8-R" /* name */
>
> - the backend's createdb() function check correct BE encoding (here was
> bug)
>
> - 'initdb' check if default template encoding is correct for backend DB.
>
> In the old code it's in initdb very hardcoded. I add to pg_encoding
> option '-b' that check if encoding is correct for backend DB (means
> encoding is not client only). It's better than
> if [ $MULTIBYTEID -gt 31 ]
> ^^^^^^
> in scripts.
>
> For example (Big5 is client only encoding):
>
> $ pg_encoding Big5
> 16
> $ pg_encoding -b Big5
> $
>
> - initdb use MULTIBYTE_NAME and "pg_encoding -b"
>
> - ODBC works with old and new names for Shift_JIS and Big5
>
> - the patch doesn't contain docs about encoding names... later :-)
>
>
> Note for CVS commit:
>
> following files are renamed:
>
> src/utils/mb/Unicode/KOI8_to_utf8.map --> src/utils/mb/Unicode/KOI8R_to_utf8.map
> src/utils/mb/Unicode/WIN_to_utf8.map --> src/utils/mb/Unicode/WIN1251_to_utf8.map
> src/utils/mb/Unicode/utf8_to_KOI8.map --> src/utils/mb/Unicode/utf8_to_KOI8R.map
> src/utils/mb/Unicode/utf8_to_WIN.map --> src/utils/mb/Unicode/utf8_to_WIN1251.map
>
> new file:
>
> src/utils/mb/encname.c
>
> removed file:
>
> src/utils/mb/common.c
>
>
> The patch doesn't contain large configure script, but only configure.in.
> Please before "cvs commit" do autoconf!
>
>
> Thanks for all suggestion.
>
> New comments?
>
> Karel
>
> --
> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
> http://home.zf.jcu.cz/~zakkr/
>
> C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2001-09-07 20:23:08 Re: [PATCHES] to_char and Roman Numeral (RN) bug
Previous Message Bruce Momjian 2001-09-07 20:11:25 Re: encoding: ODBC, createdb