Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off |
Дата | |
Msg-id | 20230202.173840.514794946954779039.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off
|
Список | pgsql-bugs |
At Thu, 02 Feb 2023 00:51:07 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in > Kyotaro Horiguchi <horikyota.ntt@gmail.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
В списке pgsql-bugs по дате отправления: