Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
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:51:07
Message-ID: 1472712.1675317067@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> 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).

Yeah ... also that's problematic if we're in a transaction, especially
an already-failed one.

Eventually I would like to remove the standard_conforming_strings GUC
altogether, primarily for the reason given at the top of gram.y:

* In general, nothing in this file should initiate database accesses
* nor depend on changeable state (such as SET variables). If you do
* database accesses, your code will fail when we have aborted the
* current transaction and are just parsing commands to find the next
* ROLLBACK or COMMIT. If you make use of SET variables, then you
* will do the wrong thing in multi-query strings like this:
* SET constraint_exclusion TO off; SELECT * FROM foo;
* because the entire string is parsed by gram.y before the SET gets
* executed. Anything that depends on the database or changeable state
* should be handled during parse analysis so that it happens at the
* right time not the wrong time.

Now, I don't foresee that actually happening any time soon (and every
report of somebody still using standard_conforming_strings = off
pushes out my idea of when it could happen). But perhaps allowing
minor annoyances like this to go unfixed would start to light a
fire under people to get off of that setting.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-02-02 07:45:03 Re: BUG #17744: Fail Assert while recoverying from pg_basebackup
Previous Message Kyotaro Horiguchi 2023-02-02 05:40:46 Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off