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 single quotes,
 >> preceded by "X", e.g. X'1a43fe'. Should we be looking at
 >> implementing the standard instead of, or in addition to,
 >> octalizing?
 >
 >
 > Perhaps we should cause the system to regard hex-strings as literals
 > of type bytea.  Right now 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


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Reply via email to