Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1pNJIb-0007pO-CH
	for pgsql-bugs@arkaria.postgresql.org; Wed, 01 Feb 2023 20:01:41 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1pNJIa-0006xX-7H
	for pgsql-bugs@arkaria.postgresql.org; Wed, 01 Feb 2023 20:01:40 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1pNJIZ-0006xN-VD
	for pgsql-bugs@lists.postgresql.org; Wed, 01 Feb 2023 20:01:39 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1pNJIX-0003l2-KO
	for pgsql-bugs@lists.postgresql.org; Wed, 01 Feb 2023 20:01:39 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 311K1Ytq1409310;
	Wed, 1 Feb 2023 15:01:34 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: takaram71@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17767: psql: tab-completion causes warnings when
 standard_conforming_strings = off
In-reply-to: <1366329.1675262563@sss.pgh.pa.us>
References: <17767-e5c80c3e56ded85c@postgresql.org>
 <1366329.1675262563@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 01 Feb 2023 09:42:43 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1409308.1675281694.1@sss.pgh.pa.us>
Date: Wed, 01 Feb 2023 15:01:34 -0500
Message-ID: <1409309.1675281694@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/1409309.1675281694%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> Step to reproduce:
>> 1. Set standard_conforming_strings = off
>> 2. Type `\d _` and press Tab key

>> Actual result:
>> Got `WARNING:  nonstandard use of \\ in a string literal`

> Yeah, that should be coded a bit more robustly.  Will fix, thanks
> for the report!

Actually, that seems to be considerably more easily said than done.
I'd thought it'd only require a localized fix, but the issue is
that tab-complete.c is depending on PQescapeStringConn which
only cares about generating a legal literal, not about avoiding
the escape_string_warning warning.  To fix, we'd need to

(1) modify what tab-complete.c's escape_string() does, which isn't hard;

(2) modify every query string that incorporates an escape_string result,
along the lines of

-" WHERE d.datname LIKE '%s' "\
+" WHERE d.datname LIKE E'%s' "\

It might be better to change to

+" WHERE d.datname LIKE %s "\

and make escape_string() responsible for adding the E and quotes,
so that it's less likely someone forgets the E.  In any case,
step (2) is going to be enormously invasive to tab-complete.c,
and there'd be substantial risk of introducing new bugs.

This problem has been there a long time, though it doesn't manifest
in exactly this way before v15 changed tab-complete's implementation
of name matching.  In v14, I can get it to happen with

\d a\b<TAB>

which is less likely to be something somebody would try.

I'm having a hard time getting excited about making such a change,
TBH.  Why is it that you are running with
standard_conforming_strings = off and escape_string_warning = on
anyway?  If you haven't yet converted your apps to support
standard-conforming strings, you probably aren't intent on
doing so in the near future, so you might as well turn off
escape_string_warning.  We last worried about silencing such
warnings in our client programs more than a dozen years ago;
I'm not sure we should still be worried in 2023.

			regards, tom lane