> And for the blobs that contain JPEG and TIFF binary compressed data?
> *YES* compression can be added *BUT* it has to be selectable rather
> than enforced?

Compressed BLOBs with JPEG or TIFF data won't hurt too much in the
scheme Jim suggests. You just loose few CPU cycles on the client. The
only type of system that might be affected is a web server running on
the same host with database server. All decompression code will eat
cycles of the same CPU - same as if we would use BLOB filters.

> At which point we get back to being able to optionally selecting the
> *TYPE* of compression rather than trying to pick one and imposing
> it? Isn't this what blob filters are a hook for?

No, because filters would consume server CPU cycles, Jim suggests to
move the [de]compression code to the client. And in general I like
this approach except two things in it:

- it does not work for isc_seek_blob, which I need (but it seems that
nobody else is concerned, so we can ignore this);

- the client library must know the physical storage format, in other
words there is no longer clean separation of the layers. We have to
measure the performance gain to decide whether it is worth it or not.

Roman