From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
cc: takaram71@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17767: psql: tab-completion causes warnings when
 standard_conforming_strings = off
In-reply-to: <20230202.144046.149191965911804616.horikyota.ntt@gmail.com>
References: <17767-e5c80c3e56ded85c@postgresql.org>
 <1366329.1675262563@sss.pgh.pa.us> <1409309.1675281694@sss.pgh.pa.us>
 <20230202.144046.149191965911804616.horikyota.ntt@gmail.com>
Comments: In-reply-to Kyotaro Horiguchi <horikyota.ntt@gmail.com>
	message dated "Thu, 02 Feb 2023 14:40:46 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1472711.1675317067.1@sss.pgh.pa.us>
Date: Thu, 02 Feb 2023 00:51:07 -0500
Message-ID: <1472712.1675317067@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1472712.1675317067%40sss.pgh.pa.us>
Precedence: bulk

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Wed, 01 Feb 2023 15:01:34 -0500, Tom Lane <tgl@sss.pgh.pa.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