Re: invalidly encoded strings

On Sun, 2007-09-09 at 17:09 -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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?
>

Agreed.

> 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.

Would stringTypeDatum() in parse_type.c be a good place to put the
pg_verifymbstr()?

Regards,
Jeff Davis