From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | takaram71(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off |
Date: | 2023-02-02 05:40:46 |
Message-ID: | 20230202.144046.149191965911804616.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
At Wed, 01 Feb 2023 15:01:34 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> 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.
I personally fine with the current behavior for the same reason as you
raised. We could enclose completion queries by "BEGIN; SET LOCAL
standard_... = on;" and "COMMIT;" in exec_query but I think you don't
like that (and me neither).
If we don't make that change, it might be good to add a note to the
documentation for standard_conforming_strings something like "Note
that setting this to off on a psql session can cause tab-completion
emit WARNING when command lines containing backslashes.", but even
that may be too noisy against the benefit..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-02 05:51:07 | Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off |
Previous Message | PG Bug reporting form | 2023-02-02 02:52:49 | BUG #17768: Assert triggered on initsplan.c |