Re: invalidly encoded strings
От | Jeff Davis |
---|---|
Тема | Re: invalidly encoded strings |
Дата | |
Msg-id | 1189360835.5924.14.camel@jdavis обсуждение исходный текст |
Ответ на | Re: invalidly encoded strings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: invalidly encoded strings
|
Список | pgsql-hackers |
On Sun, 2007-09-09 at 10:51 -0400, Tom Lane wrote: > A possible answer is to add a verifymbstr to the string literal > converter anytime it has processed a numeric backslash-escape in the > string. Open questions for that are (1) does it have negative effects > for bytea, and if so is there any hope of working around it? (2) how > can we postpone the conversion/test to the parse analysis phase? > (To the extent that database encoding is frozen it'd probably be OK > to do it in the scanner, but such a choice will come back to bite > us eventually.) Regarding #1: 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. There may be more issues, too. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: