select uncompress(concat(x’00000100′,myblob)) from mytable where id=2121;

(the value must be chosen so that it’s not too big but still can contain the output buffer)

Better yet…. it would be nice if the JDBC driver had a (de)compress BLOBs on the client option that was compatible with the internal MySQL compress/uncompress functions.

I think I might just submit a patch for that when I get around to it.

Kevin

============
Vva (the implementor):

3. As I understand, Zlib doesn’t provide function for calculation of
size of packet after uncomppress..
============
Peter:

I’ve used this library (also LZO/BZIP2) for my own application and I
used a bit different approach – storing original size in the header.
This allows to avoid uncompress in the loop which is really bad
performance wise.
Thus I did not needed compatibility with existing data, which we likely
need in our case.
============
Monty:

No, we don’t need to be compatible in this case. We can define that
our compressed string starts with a 4 byte length header + the
compressed data. Anyone that needs to access the compress data can
simply use RIGHT().

The 2 highest bits should be masked when reading the data as we
want to use this to store the compress method used.
(This will limit compressed data to 1 G, but this is ok for now)
============

At the moment, there’s only one “compress method used”, so two highest bits are always 0.

Besides, the manual

http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html#function-compress

says “The compressed string contents are stored the following way:
* Empty strings are stored as empty strings.
* Non-empty strings are stored as a four-byte length of the uncompressed string (low byte first), followed by the compressed string. If the string ends with space, an extra ‘.’ character is added to avoid problems with endspace trimming should the result be stored in a CHAR or VARCHAR column. (Use of CHAR or VARCHAR to store compressed strings is not recommended. It is better to use a BLOB column instead.)”

Looks pretty clear to me, no need to guess or read the code.

Thanks for the clarification. How can compress() use a prefix of only 4 bytes since the compressed data could in theory be up to 2^32?

The uncompress makes sense.

What’s the reason for the change in format? So that LENGTH() works?

FYI, after reading this blog entry today, I was actually just compiling MySQL 5.0.51 on a new machine and look what message popped up.

checking for zlib compression library… system-wide zlib not found, using one bundled with MySQL

Interesting isn’t it?