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

Reply via email to