Re: [Firebird-devel] Case-insensitive collations

[Ivan P. <Iva...@se...>]

One of the problems of collations is that they are All In One -
they are used for searching, sorting, uppercasing, but this
functionality is accessible in fixed and not always desired or consistent way.
E.g. when using accent-insensitive collations, I can apply
accent insensitive search (but just for some operations,
not e.g. for Containing), but I will loose nice sorting.


Would not it be better instead of adding new collations
to add new operators ?

E.g. to have case-sensitive / case-insensitive / accent-insensitive
variant CONTAINING.
Or be able to specify for multi-level collations how many levels
are significant for required operation. (thus, depending on collation,
e.g. Starting(1) could be case/accent insensitive,
Starting(2) could be accent-sensitive/case-insensitive, etc.)

Ivan


----- Original Message ----- 
From: "Peter Jacobi" <pj...@wa...>
To: <fir...@li...>
Sent: Wednesday, June 23, 2004 3:12 PM
Subject: Re: [Firebird-devel] Case-insensitive collations


> Hi Ivan, All,
> 
> > What is the reason that there are still no case/accent/diacritic-insensitive
> > built-in collations in Firebird ? Is it that some bugs prevent it, or that
> > it is more difficult than I think, or that it could be easy done but
> > difficult to ensure that it conforms to some norms, or that this area will
> > be completely reworked in FB2 so doing it now would be wasting of time, or
> > is the reason as simple as that nobody just created them ?
> 
> All of the above and then some.
> 

> A) (and very important from my POV):
> For the majority of application, no-case no-accent collations don't make 
> sense, and the 'normal' multi-level collations would fulfill all 
> requirements, if only they are used.
> As you are mentioning in your parallel 
> post, in STARTING WITH and LIKE 'foo%'
> 
> STARTING WITH 'ABC' should select 'ABCDE' and 'abcde', when a multilevel 
> collation is used.

> B) The existing multi-level collations are painfully wasteful on key 
> storage space, limiting the maximally indexable buffer size to a third of 
> the general limit. For this reasons, triplicating them into no-case and
> no-case / no-accent variants is -at least to me- wasted effort.
> 
> C) All future collation should better be seen and (partially) implemented 
> as restrictions of collations on Unicode, but the Unicode support of FB is 
> still lacking.
> 
> D) Only with FB1.5.1 it has become an options to consistently use 
> connection charset NONE (ane be it only for the lack of a better solution)
> 
> E) I am not that productive as I hoped.
> 
> F) Implementing Thai was more fun.
> 
> G) Doing some serious work on charset/collations always looks somewhat 
> wasted, due to the lack feedback - and the possibility that everything will 
> be thrown out eventually and linked against ICU.
> 
> H) Whoever needs no-case/no-accent very bad, can try my pj_colkit LOADABLE 
> collation.
> http://www.jodelpeter.de/i18n/fbarch/loadable.txt
> http://www.jodelpeter.de/i18n/fbarch/
> 
> I) I neither have a MSVC build environment nor a working Linux and never 
> managed to get MinGW working.
> 
> J) As rdb$collations and rdb$character_sets are hardcoded into the engine's 
> code, instead of being deferred from the DLLs, it's unnecessarily 
> complicated to add charscter sets and collations (and all tools will ignore 
> them)
> 
> Regards,
> Peter Jacobi