Re: Encoding names

On Thu, 22 Feb 2001, Tatsuo Ishii wrote:

> > > As you probably know, there is already a binary search algorithm coded
> > > up for the date/time string lookups in utils/adt/datetime.c. Since that
> > > lookup caches the last value (which could be done here too) most lookups
> > > are immediate.
> > > 
> > > Are you proposing to make a change Karel, or just encouraging others? :)
> > > 
> > 
> >  No problem for me. Do you want patch with this to tommorow breakfast?
> > IMHO it's acceptable for current 7.1 too, it's really small change.
> > 
> >  Or do it Tatsuo?
> 
> Please go ahead. By the way, there is one more place you need to tweak
> the encoding name table. Take a look at
> interfaces/libpq/fe-connect.c. It's ugly to have simlilar tables in
> two places, but I did not find better way to avoid to link huge
> Unicode conversion tables in the frontend.
Hmm, I see. It's realy a little ugly maintain two places with same
things. What this solution:
 * split (on backend) pg_conv_tbl[] into two tables:
encstr2enc[]     - for encoding names (strings) to encode 'id'.          This table will sort by alphabet.
pg_conv_tbl[]   - table with encoding 'id' and with encoding routines.          This table will order by encoding 'id'
andthis          order allows found relevant routines, an example:
 
pg_conv_tbl[ LATIN1 ]

This solution allows to use and share on libpq and backend one encstr2enc[] 
table and basic functions those works with this table -- like
pg_char_to_encoding().
May be will better define for encoding 'id' separate enum datetype instead
current mistake-able '#define'. 
        Karel