Thread: backslashes in 8.3.3
I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are
handled completely differently now. For example,
db=# insert into junk (cifs) values ('\\foooo\bar');
WARNING: nonstandard use of \\ in a string literal
LINE 1: insert into junk (cifs) values ('\\foooo\bar');
^
HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
INSERT 0 1
db=# select * from junk;
cifs
--------------
\foooo\x08ar
(1 row)
Is there anyway to disable this behavior or fix this on the server
side? I really don't want to have to rework all of our code that
inserts or queries data.
It seems this works,
db=# insert into junk (cifs) values (E'\\\\foobar\\bar');
INSERT 0 1
--
Brandon
"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are
> handled completely differently now. For example,
See standard_conforming_strings and escape_string_warning.
regards, tom lane
b == bmetcalf@nortel.com writes:
b> I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are
b> handled completely differently now. For example,
It looks like the default for escape_string_warning is now "on".
However, it says in the docs that future versions will treat the
backslash literally.
I suppose this means versions beyond 8.3.3?
But this is really an annoying change if I now have to go and escape
every backslash that we are inserting.
b> db=# insert into junk (cifs) values ('\\foooo\bar');
b> WARNING: nonstandard use of \\ in a string literal
b> LINE 1: insert into junk (cifs) values ('\\foooo\bar');
b> ^
b> HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
b> INSERT 0 1
b> db=# select * from junk;
b> cifs
b> --------------
b> \foooo\x08ar
b> (1 row)
b> Is there anyway to disable this behavior or fix this on the server
b> side? I really don't want to have to rework all of our code that
b> inserts or queries data.
b> It seems this works,
b> db=# insert into junk (cifs) values (E'\\\\foobar\\bar');
b> INSERT 0 1
--
Brandon
t == tgl@sss.pgh.pa.us writes: t> "Brandon Metcalf" <bmetcalf@nortel.com> writes: t> > I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are t> > handled completely differently now. For example, t> See standard_conforming_strings and escape_string_warning. Excellent. I had missed the standard_conforming_strings and will turn this on. Hold on. Yes, that did it. Thanks so much. -- Brandon
"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> t == tgl@sss.pgh.pa.us writes:
> t> See standard_conforming_strings and escape_string_warning.
> Excellent. I had missed the standard_conforming_strings and will turn
> this on. Hold on. Yes, that did it. Thanks so much.
Well, if your intent is to replicate 8.1's behavior, you should instead
frob the other switch.
regards, tom lane
t == tgl@sss.pgh.pa.us writes: t> "Brandon Metcalf" <bmetcalf@nortel.com> writes: t> > t == tgl@sss.pgh.pa.us writes: t> > t> See standard_conforming_strings and escape_string_warning. t> > Excellent. I had missed the standard_conforming_strings and will turn t> > this on. Hold on. Yes, that did it. Thanks so much. t> Well, if your intent is to replicate 8.1's behavior, you should instead t> frob the other switch. I now have escape_string_warning = off and standard_conforming_strings = on in postgresql.conf and things are back to how they were. That is no warnings and backslashes treated literally. A related question, is it in any way possible that a control sequence could have been sent from a client that caused a fast shutdown? Our server log shows a fast shutdown request last night, but nobody manually issued such a request. -- Brandon
"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> t == tgl@sss.pgh.pa.us writes:
> t> Well, if your intent is to replicate 8.1's behavior, you should instead
> t> frob the other switch.
> I now have
> escape_string_warning = off
> and
> standard_conforming_strings = on
> in postgresql.conf and things are back to how they were. That is no
> warnings and backslashes treated literally.
Uh, no, that is certainly *not* the behavior you were getting in 8.1;
8.1's behavior corresponds to both switches off.
> A related question, is it in any way possible that a control sequence
> could have been sent from a client that caused a fast shutdown? Our
> server log shows a fast shutdown request last night, but nobody
> manually issued such a request.
Fast shutdown means something sent SIGINT to the postmaster.
The only way I've heard for that to happen "accidentally" is
if you normally launch the postmaster by hand in a way that
leaves it attached to your terminal session --- then control-C
in that session would SIGINT the postmaster.
regards, tom lane
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
"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> t == tgl@sss.pgh.pa.us writes:
> 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.
Maybe something changed on the client side? 8.1 definitely does not have
standard_conforming_strings, but perhaps you had some client-side
code that compensated by inserting backslashes.
regards, tom lane
t == tgl@sss.pgh.pa.us writes: t> "Brandon Metcalf" <bmetcalf@nortel.com> writes: t> > t == tgl@sss.pgh.pa.us writes: t> > t> Uh, no, that is certainly *not* the behavior you were getting in 8.1; t> > t> 8.1's behavior corresponds to both switches off. t> > OK. I'm confused. With 8.1.5 we never had to do anything special t> > with backslashes. When we upgraded to 8.3.3, backslashes in our t> > INSERTs caused problems until we turn _on_ t> > standard_conforming_strings. t> Maybe something changed on the client side? 8.1 definitely does not have t> standard_conforming_strings, but perhaps you had some client-side t> code that compensated by inserting backslashes. No, nothing changed on the client side. I know you know what you're talking about, though. At any rate, I've got the behavior I need now. -- Brandon