Re: [PATCHES] Escape handling in strings

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.)

I would be inclined to leave things like that for a couple of release
cycles before we disable backslashes in regular literals. By the time
we do that, we should have at least flushed out the cases where
disabling backslashes will create security holes.

> I think we're going to need to provide for switchable behaviour, as ugly
> as that might be (looking briefly at scan.l it looks like the simplest
> way would be a separate state for being inside standard strings, with
> the choice of state being made conditionally in the {xqstart} rule).

I really really dislike that idea; it is a recipe for creating problems
not solving them.

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.

regards, tom lane