Robert,

R> That's compelling enough for me. Do you know why that is?

I think that the original thought was to let a network layer do the
compression, instead of doing it in the engine.

R> If I have a
R> type that may vary in length from say 100 characters to 10k characters,
R> it has to send a 10k buffer across? I don't get it. Is this the case
R> even with Firebird?

I think so; I think InterBase 7 removed this one, and it's an open
issue in Firebird also.

R> We want to store registry paths, which can be arbitrarily long.
R> Unfortunately, you can't index on a blob so a lookup on a path could
R> take a long time.

As Martijn says, you can't even index a varchar over approx. 250
characters (or less if you use MBCSs).
Increasing the maximum index key size is also on Firebird's agenda. I
believe the Firebird Foundation would be glad to implement these
features if someone would sponsor them.

R> I think what we will do is create a size limitted varchar for user
R> collation, indexing, searching, and displaying. The raw complete name as
R> a BLOB, and a hash of the complete string for lookup by the underlying
R> implementation (which needs to find a row using the entire,
R> non-truncated path). Hmmm....any other suggestions?

Looks nice to me. A lot of additional work, but nice.

Ciao
--
Nando mailto:nandod@...