Re: invalidly encoded strings
От | Tom Lane |
---|---|
Тема | Re: invalidly encoded strings |
Дата | |
Msg-id | 4445.1189372176@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: invalidly encoded strings (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: invalidly encoded strings
|
Список | 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 по дате отправления: