Andrew Dunstan wrote: > Bruce Momjian said: > > > OK, the current patch warns about two things, \' with one message, and > > any backslash in a non-E string with a different message. The \' > > message can easily be avoided in clients even in 8.0 by using '', but > > for E'', there is no way to prepare an application before upgrading to > > 8.1 because 8.0 doesn't have E''. (We can add E'' in a subrelease, but > > what percentage of users are going to upgrade to that?) This is why I > > think we need to add a GUC to allow the warning to be turned off. To > > be clear, the GUC is to control the warning, not the query behavior.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > We could go with the second warning only in 8.2, but that seems too > > confusing --- we should deal with the escape issue in two stages, > > rather than three. > > > > So you don't agree with Tom's suggestion to implement E'' a full cycle > before removing backslash processing in standard strings? Or have I > misunderstood again? I think you misunderstood. There is no scheduled date to change the actual behavior. The issue is whether we delay one release before issuing a warning for backslashes in non-E strings. I have highlighted the sentence where I say we are talking about when to add the warning, not when to change the behavior. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
