Vlad Horsun wrote:

>>We may be able to do the same thing with long strings. Firebird 2
>>doesn't need to limit the index key at all, just truncate it at the
>>maximum length that can be supported for the current page size, after
>>the key is built, but before prefix compression.
>>
>>
>
> Alternatively, FB2 has expression indexes. With it users can
>exactly define its own truncation rules for long keys. Its can be
>simple SUBSTRING, but it also can be some kind of hashing - all
>depends on use cases which only database developers knows.
>
>
>

Vlad, you missed the point. Imprecise indexes preserve SQL search
semantics.

There were two reasons why I was willing to live with the original 255
key limit. The first was that we didn't support multi-byte character
sets, so 255 bytes meant 255 real characters or at least around 200 for
multi-part indexes. I know that people almost always over specify
fields to handle the worst case imaginable, but the probability of the
worst case imaginable in all segments was diminishingly small. So in
the original implementation, the key limits were enforced at data
definition time. Borland had a different opinion and with multi-byte
character sets, a different environment.

Ann's observation / proposal is a compromise between the original
philosophy -- that fields are always over specified -- with the idea
that a runtime error is a nasty surprise. In all probablility, close to
100% of all key will be precise, but the exception can still be handled
correctly.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376