> They're called text blobs :-)

When I must use blobs, I gotta treat them differently, according to
their own usage and limitations. If I need fast search, I gotta make
up a dictionary table around them and populate it. Another for
sorting. Gotta hash them to compare them. All sorts of work I expect
from a database to do for me. I gotta check with my fb library see if
they are supported well (there are still issues with php and python
libs for example, fibplus used to have some problems in the past). So
I avoid them whenever possible. Frankly I wish they never be invented,
so the record size limitation would be gone by now by necessity.

>
> Although if you want to index them, nobody will promise you that
> regardless of whether it's a string or a blob. Maybe this could help
> though: http://tracker.firebirdsql.org/browse/CORE-2201.
>

I'm watching that thread but I wasn't sure I should vote fore it, by
the same reasoning above: I hope for more orthogonal solutions.

Those limited indexes would solve sorting. Add hash indexes to that to
solve equality comparison. Partial equality based on the beginning of
the string is not so useful in practice IMO.

I remember you (if I'm not mistaken) arguing that btree indexing is
useless anyway for large strings, but in practice, that is irrelevant
since 99% will be small strings anyway and shouldn't affect
performance (the btree walker wouldn't call for the deep branches).