Re: Unexpected behaviour of encode()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unexpected behaviour of encode()
Дата
Msg-id 16965.1364323658@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unexpected behaviour of encode()  (Bill Moran <wmoran@potentialtech.com>)
Список pgsql-general
Bill Moran <wmoran@potentialtech.com> writes:
> If I just do:
> SELECT 'can''t'::text;
> I get "can't" which is what I'd expect.  I would then expect
> encode to escape the ' somehow.  Even c-style escaping, like
> "can\'t" would have been less surprising to me.

> If there's something I'm missing, I'm still missing it.

The manual says that 'escape' encoding "merely outputs null bytes as
\000 and doubles backslashes".  (The reason to double backslashes is to
make \000 unambiguous, of course.)  The point of this is to sanitize
bytea data sufficiently to allow it to be transported as text.  If you
want to transport it as a SQL literal, that's a tighter constraint that
would require some other escaping method, or at least passing the result
through something like quote_literal.

(Having said that, I wonder though if "escape" doesn't need more
thought.  The output is only valid text in SQL_ASCII or single-byte
encodings, otherwise there's risk of encoding violations.)

            regards, tom lane


В списке pgsql-general по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Unexpected behaviour of encode()
Следующее
От: Laurence Rowe
Дата:
Сообщение: Building an invalidation queue in Postgres