Re: [Firebird-devel] Case-insensitive collations

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

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

Yes, but it (Starting With) will become accent-insensitive at the same time,
somebody may want it, somebody do not.
Nearly everybody (I believe) is content with sorting capabilities
provided by multi-level collations, it is searching capabilities that
cause troubles.
This is why I said that we need more operators/functions, not collations.
(e.g. new case-insensitive STARTING, instead of changing its current
behaviour)

In other words, ordering is property of data,
but case/accent-insensitivity should be property of operation
on those data (at least in some cases. Of course =,<,>
must match the ordering, but I see no reason why the user
should not be able to choose from case/accent-sens/insens
variants of Containing). As Peter suggested, combination
of expression-indexes and Noaccent() variant of Upper()
can satisfy such needs too.


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

Yes, and I noticed that many existing collations are in fact two-level only,
yet they require three bytes.



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

(I probably already asked this, but forgot the answer:)
Does this change apply to client-server communication only, or is it
consistent everywhere (e.g. Update Tab Set Iso8859Column = NoneColumn;)


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

I tried to write some external collation drivers too (using Delphi),
and it is not much difficult, but such approach has its drawbacks too:
- more complicated installation
- even custom collations can't solve many requirements
- narrow range for external collation_ids (250..254).
  These Charset_id/Collation_id numeric values are used
  directly e.g. in SP/Trigers blr, and there is no additional mapping
  (e.g. through system tables) between external/internal ids,
  thus it is dangerous to expect that nobody else has taken these numbers
  by different driver.


Ivan