Re: invalidly encoded strings
От | Tom Lane |
---|---|
Тема | Re: invalidly encoded strings |
Дата | |
Msg-id | 3872.1189433674@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: invalidly encoded strings (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> Those should be checked already --- if not, the right fix is still to >> fix it there, not in per-datatype code. I think we are OK though, >> eg see "need_transcoding" logic in copy.c. > Well, a little experimentation shows that we currently are not OK: > in foo.data: > \366\66 I looked at this and found that the problem is that CopyReadAttributesText() does backslash conversions and doesn't validate the result. My proposal at this point is that both scan.l and CopyReadAttributesText need to guarantee that the result of de-escaping is valid in the database encoding: they should reject \0 and check validity of multibyte characters. You could optimize this fairly well (important in the COPY case) by not redoing verifymbstr unless you'd seen at least one numerical backslash-escape that set the high bit. regards, tom lane
В списке pgsql-hackers по дате отправления: