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