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