Re: invalidly encoded strings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: invalidly encoded strings
Date: 2007-09-09 21:09:36
Message-ID: 4445.1189372176@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-09-09 21:15:33 Re: Are we done with sync-commit-defaults-to-off patch?
Previous Message Tom Lane 2007-09-09 21:06:01 Re: invalidly encoded strings

Browse pgsql-patches by date

  From Date Subject
Next Message Jeff Davis 2007-09-09 22:04:01 Re: invalidly encoded strings
Previous Message Tom Lane 2007-09-09 21:06:01 Re: invalidly encoded strings