In the course of a different discussion, someone asked about
indexing arbitrarily large objects - very long char/varchar
and blobs. People who do that normally create a second field
that contains a hash of the long field and index the second
field. In Firebird 2, one could create an expression index
and avoid the second field.

However, if that capability were internalized, Firebird could
also do the second check to recognize whether a hash collision
was actually a match or just a collision. That would allow
us to create reliable indexes - including unique indexes on
long strings and blobs, regardless of the blob type.

The index itself would be a standard btree using the hash
as the value. It would be useless for returning records
in sorted order - but good for retrieval and unique
constraints. From the application perspective, there would
be no difference in definition - just removing the limit on
the length of the key.

Thoughts?


Regards,


Ann