Re: backslashes in 8.3.3

Поиск
Список
Период
Сортировка
От Brandon Metcalf
Тема Re: backslashes in 8.3.3
Дата
Msg-id Pine.LNX.4.58L.0806241200050.9186@cash.us.nortel.com
обсуждение исходный текст
Ответ на Re: backslashes in 8.3.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: backslashes in 8.3.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
t == tgl@sss.pgh.pa.us writes:

 t> "Brandon Metcalf" <bmetcalf@nortel.com> writes:
 t> > t == tgl@sss.pgh.pa.us writes:
 t> >  t> Well, if your intent is to replicate 8.1's behavior, you should instead
 t> >  t> frob the other switch.

 t> > I now have
 t> >   escape_string_warning = off
 t> > and
 t> >   standard_conforming_strings = on
 t> > in postgresql.conf and things are back to how they were.  That is no
 t> > warnings and backslashes treated literally.

 t> Uh, no, that is certainly *not* the behavior you were getting in 8.1;
 t> 8.1's behavior corresponds to both switches off.

OK.  I'm confused.  With 8.1.5 we never had to do anything special
with backslashes.  When we upgraded to 8.3.3, backslashes in our
INSERTs caused problems until we turn _on_
standard_conforming_strings.

 t> > A related question, is it in any way possible that a control sequence
 t> > could have been sent from a client that caused a fast shutdown?  Our
 t> > server log shows a fast shutdown request last night, but nobody
 t> > manually issued such a request.

 t> Fast shutdown means something sent SIGINT to the postmaster.
 t> The only way I've heard for that to happen "accidentally" is
 t> if you normally launch the postmaster by hand in a way that
 t> leaves it attached to your terminal session --- then control-C
 t> in that session would SIGINT the postmaster.

That could have been it.


--
Brandon

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

Предыдущее
От: Karsten Hilbert
Дата:
Сообщение: Re: String Encoding Conversion Problem
Следующее
От: Jorge Godoy
Дата:
Сообщение: Re: Probably been asked a hundred times before.