Re: PQescapeBytea is not multibyte aware

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