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  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: invalidly encoded strings
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Are we done with sync-commit-defaults-to-off patch?