Josh Kupershmidt <schmiddy@gmail.com> writes:
> On Wed, May 2, 2012 at 11:21 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> On Wed, May 02, 2012 at 12:59:58PM +0000, stuart@stuartbishop.net wrote:
>>> # CREATE SEQUENCE "\foo";
>>> CREATE SEQUENCE
>>> # \ds "\
>> I am unable to reproduce this failure on my copy of 9.1.3. Have you
>> perhaps changed any server settings?
> I only get the error if I:
> SET standard_conforming_strings TO off;
> otherwise, it works fine. Perhaps it's still worth fixing though.
AFAICT, you get this behavior in every release back to 8.1, if you have
both escape_string_warning ON and standard_conforming_strings OFF;
which was the default configuration from 8.2 through 9.0. The lack of
prior complaints suggests pretty strongly that backslashes in names are
not common in the field.
The only way we could suppress such warnings would be if we made
tab-complete.c use E'' strings for literals containing name prefixes;
which is perhaps doable but it would mean having tab-complete.c roll
its own string escaping rather than use any facility now available
from libpq. (PQescapeString and friends presume that the result will
be emitted as a plain string.)
This issue isn't peculiar to tab-complete.c, either; in general, *any*
client that uses PQescapeString and friends is going to get bombarded
with this type of warning when the server is configured that way, even
though what it's doing is perfectly safe. I don't remember at the
moment why we designed those functions that way, but presumably the
alternatives were worse.
I'm inclined to think that if we got this far without complaint, there's
not a lot of point in writing new string-escaping support to solve what
is now a legacy problem.
regards, tom lane
