Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Escape handling in strings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Rod Taylor <pg(at)rbt(dot)ca>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Subject: Re: [PATCHES] Escape handling in strings
Date: 2005-06-16 16:00:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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

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

In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2005-06-16 16:01:15
Subject: Re: Autovacuum in the backend
Previous:From: Tom LaneDate: 2005-06-16 15:42:01
Subject: Re: Autovacuum in the backend

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-06-16 17:53:59
Subject: Re: fsync under win32
Previous:From: Andrew DunstanDate: 2005-06-16 15:25:23
Subject: Re: [PATCHES] Escape handling in strings

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group