Re: invalidly encoded strings - Mailing list pgsql-hackers

From Tom Lane
Subject Re: invalidly encoded strings
Date
Msg-id 4445.1189372176@sss.pgh.pa.us
Whole thread Raw
In response to Re: invalidly encoded strings  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: invalidly encoded strings  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> Currently, you can pass a bytea literal as either: E'\377\377\377' or
> E'\\377\\377\\377'.

> The first strategy (single backslash) is not correct, because if you do
> E'\377\000\377', the embedded null character counts as the end of the
> cstring, even though there are bytes after it. Similar strange things
> happen if you have a E'\134' (backslash) somewhere in the string.
> However, I have no doubt that there are people who use the first
> strategy anyway, and the proposed change would break that for them.

If their code is broken anyway, calling their attention to it would be a
good idea, hm?

If we are not going to reject the embedded-null case then there is
hardly any point in considering any behavioral change at all here.
I want to point out in particular that Andrew's proposal of making
datatype input functions responsible for encoding verification cannot
possibly handle this, since they have to take the "terminating" null
at face value.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: invalidly encoded strings
Next
From: Tom Lane
Date:
Subject: Re: Are we done with sync-commit-defaults-to-off patch?