woodsmailbox wrote:

> When I must use blobs, I gotta treat them differently, according to
> their own usage and limitations.

As for the usage, I dunno what prevents you from using them as "large
enough" strings. They now support searching operations, upper/lower,
substring/trim, charsets/collations, etc. They don't support ordering
though.

> I avoid them whenever possible. Frankly I wish they never be invented,
> so the record size limitation would be gone by now by necessity.

If being on your place, I'd rather go the opposite way.

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

That feature request is maybe 100 times easier to implement than your
"orthogonal solutions".

> Those limited indexes would solve sorting.

Nope, they don't address sorting at all. At least not in the current
implementation.

> Add hash indexes to that to solve equality comparison.

PostgreSQL had implemented hash indices and now claim them being a bad
idea no longer recommended to use. I don't want us stepping on the same
rake.

> Partial equality based on the beginning of
> the string is not so useful in practice IMO.

You seem not knowing how FB indices work. Every index scan is imprecise
and requires to re-validate the fetched record against the predicate. So
the "beginning" scan just returns possible candidates which are then
re-compared at the record level (with full string length). So you will
never notice the difference, except the index creation time.


Dmitry