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' and this
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