Tom Lane wrote:>> Yuck! At that point you're no better off than converting to hex>> (and worse off than converting to
base64)for storage.>>> No; the *storage* is still compact, it's just the I/O representation> that's not.
Yeah, I realized that after I pushed send ;)
But still, doesn't that mean roughly twice as much memory usage for each
copy of the string? And I seem to remember Jan saying that each datum
winds up having 4 copies in memory. It ends up impacting the practical
length limit for a bytea value.
>>>> SQL99 actually defines BLOB as a binary string literal comprised>> of an even number of hexadecimal digits, in
singlequotes,>> preceded by "X", e.g. X'1a43fe'. Should we be looking at>> implementing the standard instead of, or in
additionto,>> octalizing?>>> Perhaps we should cause the system to regard hex-strings as literals> of type bytea.
Rightnow I think they're taken to be integer> constants, which is clearly not per spec.
Wow. I didn't realize this was possible:
test=# select X'ffff'; ?column?
---------- 65535
(1 row)
This does clearly conflict with the spec, but what about backward
compatibility? Do you think many people use this capability?
Joe
