encoding names

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Subject: encoding names
Date: 2001-08-15 12:45:26
Message-ID: 20010815144526.A3069@zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hi,

before some time I was discuss with Tatsuo and Thomas about support
for synonyms of encoding names (for example allows to use
"ISO-8859-1" as the encoding name) and use binary search for searching
in encoding names.
I mean that we can during this change a little clean up encoding
stuff too. Now PG use for same operations with encoding names different
routines on FE and BE. IMHO it's a little strange. Well, here is a
possible solution:

- use 'enum' instead current #define for encoding identificators
(in pg_wchar.h).

- create separate table only with encoding names for conversion from
encoding name (char) to encoding numerical identificator,
and searching routines based on binary search (from Knut -- see
datetime.c).

All these will *shared* between FE and BE.

- For BE create table that handle conversion functions (like current
pg_conv_tbl[]). All items in this table will available by access to
array, like 'pg_conv_tbl[ LATIN1 ]', instead current search via for()
cycle.

May be also define all tables as 'static' and work with it by some
routines only. PG has like robust code :-)

Comments, better ideas?

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2001-08-15 12:54:35 Re: UB-Trees
Previous Message Wald, Matthias 2001-08-15 12:18:35 UB-Trees