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 08:38:40 |
Message-ID: | 20230202.173840.514794946954779039.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
At Thu, 02 Feb 2023 00:51:07 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> > 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.
(Oops!)
> 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.
That seems like the right decision for to-be-obsolete features. Or,
we can explicitly mar that variables as OBSOLETE then rip off it a few
years later.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2023-02-02 09:13:18 | Re: BUG #17768: Assert triggered on initsplan.c |
Previous Message | Kyotaro Horiguchi | 2023-02-02 07:45:03 | Re: BUG #17744: Fail Assert while recoverying from pg_basebackup |