> The more I think about, the more I think that blobs should always be
> stored compressed, but that compression/decompression be performed
> primarily on the client side. The implication is that the plumbing
> needs to be compression aware at least at the lower levels of the API.
> If we're going to build in end to end compression, we pretty much need
> to standardize on a single compression schema, and zlib is the obvious
> candidate.
>
> Now, having taken a position, can we have the opposing opinion from
> Dmitry?

I'm not Dmitry, but it seems that I have an opposing opinion. I want
to have a seek operation defined for BLOBs. This works very well for a
big BLOBs with a record-like structure, where only small parts of that
stream are needed on the client. So, I need uncompressed BLOB, since
speed of accessing that small blocks is more important for me than space.

Most likely we need another approach to BLOBs at all. Currently it is
only byte stream, BLOB types are mainly needed for filters. However it
seems that we need a full type support for TEXT type (should include
character set in declaration or store text in unicode), COMPRESSED
type (actually a BLOB, but stored in compressed form, probably with an
attribute saying the type of compression - zip, gzip, bzip2, etc.),
BINARY type (just a byte stream). There is no need to convert TEXT to
COMPRESSED or COMPRESSED into BINARY, those are independent types with
their own attributes. Something similar to the ARRAY data type.

Roman