> Why client must know physical storage? It just gets a coded buffer and
> description how it is coded (compressed), then client will just
> decompress it. Or I am missing something?

Maybe I was wrong. I meant that client library must know that what is
sent from the server or the engine must be decompressed. I assumed
that with Vulcan architecture application would load the DB engine
library directly, but I suspect that this will go via the client
library anyway. So, the implication is that we have to have two APIs -
one for the application (our current Firebird API) and one between db
engine and client library.

Jim, if this is so, wouldn't it be easier to introduce a new data type
with compression and new API calls for it (in fact, isc_get_segment
conceptually has nothing to do with a byte stream)? Something like:

fb_read_bytes(fb_blob_handle* handle, char* buffer, int64 size);
fb_write_bytes(fb_blob_handle* handle, char* buffer, int64 size);

Roman