Hi,

>> Beside that a BLOB field doesn't always contain
>> the same type of "data". Who knows what in the future gets into the
>> blob. Therefore i don't like the idea that compression should become
>> an option.
>
> What solution can you suggest in this case for a seek operation? You
> see that compressed blob and seek within such blob do not work
> together. Making compression compulsory means that isc_seek_blob must
> be deprecated, at least that's how I understand the proposal.

I've never used seek_blob so i can oversee a problem here, but can we not "simple" decompress it in
memory and do the seek. Assuming that the compression is done in blocks it wouldn't use much more
memory than now.

>> Also i would suggest that the compression is not only done on
>> BLOB-data, but on every "large" data-block for whatever data-type.
>> If the size of the data-block is bigger than size X then perform
>> compression. Why only for BLOBs, i think this shouldn't be dependend
>> on data-type.
>
> How are you going to use this for the record deltas? Or should record
> deltas be abandoned completely?

It's done per field/item, so the delta's will be still small and possible:

edsNull, edsIntLen5, <data>, edsCompression, edsZip, <data>, edsIntLen4, <data>,
edsCompression, edsZip, <data>, ...

The <data> inside edsCompression can contain compressed :
- edsUtf8Count2, <data>
- edsOpaqueCount3, <data>
- or whatever other type

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Interbase and Firebird users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info