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