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
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 |