Pavel,

P> Yes, from user's point of view, it may *looks* like a limit removal, but
P> it is NOT, it's different type of index altogether (don't get fooled
P> that it's still a B-tree), with different characteristics. If it would
P> be ever accepted, I would be strongly against implementation that would
P> not require explicit declaration when this index should be used, and
P> would use normal index definition syntax with some magic number for key
P> size when things would start to work differently.

Mmm... Firebird, just like othr fellow RDBMSs, is full of magic
numbers already; but your point (and Dmitry's, AFAIU) of "incomplete"
indexes, useless for ordering (although anybody learns pretty soon
that indexes are almost never to be used for ordering) and partial
matches, is a good one.

OTOH, Firebird is about the only top-level RDBMS that doesn't feature
different types of indexes for different purposes. I don't think there
can be a definitive word whether this is good or bad, but I can say
that I don't think that a special type of index, only useful for
uniqueness and exact matches on large objects, would be a heresy in
itself.

Ciao
--
Nando Dessena