Re: BUG #6624: Tab completion of identifier containing single backslash triggers warnings - Mailing list pgsql-bugs

From Robert Haas
Subject Re: BUG #6624: Tab completion of identifier containing single backslash triggers warnings
Date
Msg-id CA+TgmoaXCTWGwY=keTteSQtmX0w=DSu=tB+N8LS98+Uo5_LHoA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #6624: Tab completion of identifier containing single backslash triggers warnings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, May 10, 2012 at 9:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, May 2, 2012 at 6:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
>> PQescapeLiteral will do the job, no? =A0At least in 9.0+.
>
> Hmm ... it would, but then psql would fail entirely when talking to
> pre-8.1 servers, so we'd need to check the server version to decide
> which quoting method to use. =A0Do you think this is important enough to
> add yet more version-specific tests to that code?

That's a good question.  I don't think I personally have the time in
my budget to go write the code for this, but I wouldn't complain if
somebody else went and made it work.

Another question is - what exactly is our ambition in terms of
maintaining psql compatibility with old versions?  According to the
header comment in describe.c, right now we're aiming for compatibility
with anything >=3D 7.4.  Presumably at some point we're going to throw
7.4 and 8.0 under the bus, at which point we could do this more
simply, but I'm not sure how long we want to want to wait before doing
that.  If, for example, we're going to be willing to pull the plug in
9.3, then it's probably not worth putting in any effort now.  But if
we're not going to be willing to pull the plug for another 5 years,
maybe it is.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-bugs by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
Next
From: Tom Lane
Date:
Subject: Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"