> From: "Jason Wharton" <jwharton@...>
> In my view removing whitespace is different than compression. Especially
> since in InterBase it isn't "white". I noticed that with VARCHAR columns
> that if I use a random fill pattern in the unused bytes that they come

back

> verbatim. This was my first clue that InterBase was not trimming

whitespace

> out of the network packets.

Hmm... could it be that the client is uncompressing the data?

I think you misunderstood Ann. I understood her to say that _InterBase_ is
performing some compression of data as it's assembling the packets. It's
not being compressed transparently by NICs or IP drivers. Therefore, the
InterBase client has to uncompress the values and recreate XSQLDAs from the
data it receives in packets.

> I would also like to argue that these are two different issues because

when

> InterBase is populating packets to send over the wire it knows nothing

about

> what hardware or software compression is performed and as such it cuts off
> the packet's fill point at a fixed packet size boundry. It isn't able to
> overstuff a packet to 80K knowing that compression algorithm X is being

used

> in order to get it down to the 64K size.

I recall that the InterBase protocol packet size in 6.0 is hardcoded at a
length close to, but not exactly, 8 kilobytes. 8112 bytes is stuck in my
memory, whether that is correct I cannot say.

In any event, it is not a good idea for InterBase to _remove_ information
from data that is returned, even if it is whitespace. It is entirely
application-dependent whether that trailing whitespace is significant or
not, and it is not the place of the RDBMS server to make that call.

Bill Karwin