From: =?UTF-8?Q?Andr=C3=A9_H=C3=A4nsel?= <andre@webkr.de>
To: "'Bruce Momjian'" <bruce@momjian.us>,
	<orchideric@yahoo.com>,
	<pgsql-bugs@lists.postgresql.org>
References: <153642745785.23144.1699125571356845227@wrigleys.postgresql.org>
 <20180908173648.GJ28811@momjian.us>
In-Reply-To: <20180908173648.GJ28811@momjian.us>
Subject: AW: BUG #15373: null / utf-8
Date: Sat, 8 Sep 2018 21:43:18 +0200
Message-ID: <12e601d447ac$345994a0$9d0cbde0$@webkr.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKVZYTT+rPULkyux9C3qlGaQLmPOAIVdnO4o1PhjjA=
Content-Language: de
Precedence: bulk

Bruce Momjian wrote:
=20
> On Sat, Sep  8, 2018 at 05:24:17PM +0000, PG Bug reporting form wrote:
>> doesn=E2=80=99t 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.=20

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