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
