christoph.huesler(a)css.ch wrote:
Bryan wrote:
Hex takes two bytes per byte, while binary takes
one byte per byte. Is
there any reason not store binary values as binary data, even though
they may be used later in an other representation?
Well, I guess you're wrong here... one hex digit is four bits, thus half a
byte. A byte in hex isn't any different as a byte in binary, hex is just
another representation of the same value in binary form, takes up the same
space _and is stored in exact the same physical representation as binary_.
0x10 in hex is 16 in decimal and stored as one byte.
00010000 in binary is 16 in decimal and stored as one byte.
Of course, when you think I am wrong please say so ;)
I think all of this is pretty much taken for granted. The problem the OP
was no doubt referring to is that the PostgreSQL client library makes it
relatively difficult to load and store binary values, requiring a special
kind of escaping and unescaping. Cryptographic hashes are conventionally
represented in hexadecimal form. Indeed the PHP hash functions output in
hex form unconditionally, and the Math.php code goes to some trouble to
convert them to binary. That's why the design choice was a strange one.
But the designer would have been unaware of the PostgreSQL issues.
The solution to the PostgreSQL binary problem (which affects various
things apart from Math.php) is to call encodeBlob() and decodeBlob() on
data, which do nothing for MySQL but call pg_escape_bytea() and
pg_unescape_bytea() for PostgreSQL.
-- Tim Starling