Re: [PATCHES] Escape handling in strings

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > All true. Conversely, there does need to be a path for us to get to
> > standard behaviour.
>
> Yes --- but the important word there is "path". I think we have to do
> this in stages over a number of releases, to give people time to
> migrate.
>
> Assuming that the end result we want to get to is:
> 1. Plain '...' literals are per SQL spec: '' for embedded
> quotes, backslashes are not special.
> 2. We add a construct E'...' that handles backslash escapes
> the same way '...' literals do today.
>
> I think what would be reasonable for 8.1 is to create the E'...'
> construct --- which will not cause any backwards compatibility issues
> that I can see --- document it and encourage people to migrate,
> and start throwing warnings about use of \' in non-E literals.
> (We could have a GUC variable to suppress the warnings; I'm of
> the opinion that it would be better not to, though, because the point
> is to get people out of that habit sooner rather than later.)

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.

> The hard part in all this is to create apps that will survive the
> transition gracefully. I think the only way for that is to implement
> a reporting feature that lets the app know whether backslahes are
> special in plain literals or not. We already have the mechanism for
> that, ie read-only GUC variables with GUC_REPORT enabled (which we use
> for integer datetimes, for instance). But I really believe it is
> important that this be a *read only* thing not something that can be
> flipped around at runtime. Anyway, the reporting variable is another
> thing that should appear in 8.1.

OK, adding.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073