Josh Kupershmidt <schmi...@gmail.com> writes: > On Wed, May 2, 2012 at 11:21 AM, Bruce Momjian <br...@momjian.us> wrote: >> On Wed, May 02, 2012 at 12:59:58PM +0000, stu...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs