Re: Backslash handling in strings

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Backslash handling in strings
Дата
Msg-id 8400.1117517149@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Backslash handling in strings  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Backslash handling in strings  (Dennis Bjorklund <db@zigo.dhs.org>)
Re: Backslash handling in strings  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> The only thing I'm not clear on is what exactly is the use case for E''
> strings. That is, who do you expect to actually use them?

The case that convinced me we need to keep some sort of backslash
capability is this: suppose you want to put a string including a tab
into your database.  Try to do it with psql:t=> insert into foo values ('<TAB>
Guess what: you won't get anywhere, at least not unless you disable
readline.  So it's nice to be able to use \t.

There are related issues involving \r and \n depending on your platform.
And this doesn't even scratch the surface of encoding-related funnies.

So there's definitely a use-case for keeping the existing backslash
behavior, and E'string' seems like a reasonable proposal for doing that
without conflicting with the SQL spec.

What I do not see at the moment is how we get there from here (ie,
dropping backslashing in regular literals) without incurring tremendous
pain --- including breaking all existing pg_dump files, introducing
security holes and/or data corruption into many existing apps that are
not presently broken, and probably some other ways of ruining your day.
I'm quite unconvinced that this particular letter of the SQL spec is
worth complying with ...
        regards, tom lane


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

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Consumer-grade vs enterprise-grade disk drives
Следующее
От: Tom Lane
Дата:
Сообщение: Re: A 2 phase commit weirdness