Bruce Momjian wrote:
> On Sat, Sep 8, 2018 at 05:24:17PM +0000, PG Bug reporting form wrote:
>> doesn’t support converting NULL bytes to UTF-8 and therefore returns an
>> error
> You need to encode binary values containing nulls as bytea strings.
Actually this reminds me to log a documentation bug, or rather improvement.
It is already slightly confusing that Postgres doesn't support null bytes
in text columns at all and in bytea columns cannot take them in as a normal
string literal. I'm assuming this is traditional and difficult to change.
Now, there are two formats in which bytea column content can be specified,
the "hex" and the deprecated "escape" format.
This "escape" format is called that way because it allows escape sequences
which are un-escaped before the data is written to the column. This step is
comparable to the parsing of JSON for jsonb columns or the parsing of array
syntax for any array type.
However, during the parsing of an SQL there is a second, completely
different, un-escaping step going on, the un-escaping of C-style escapes in
string literals starting with an "E", *if* you start the string literal
with an "E".
For some reason the example given in the documentation for the "hex"
format uses such an "escape string literal":
SELECT E'\\xDEADBEEF';
I found this very confusing. Can this example be changed to a normal
string literal, like this?
SELECT '\xDEADBEEF';
Regards, Andre
