Re: [BUGS] BUG #14512: Backslashes in LIKE
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14512: Backslashes in LIKE |
Дата | |
Msg-id | 28169.1489781085@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14512: Backslashes in LIKE ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-bugs |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > On Fri, Mar 17, 2017 at 11:16 AM, Alex Malek <magicagent@gmail.com> wrote: >> Given the current behavior the same query will work or raise on error >> based on context. > Recently discussed here: > https://www.postgresql.org/message-id/flat/20170124172505.1431.56735%40wrigleys.postgresql.org#20170124172505.1431.56735@wrigleys.postgresql.org > In short - preventing a "fails-to-fail" scenario here doesn't seem worthy > of the effort and run-time cost doing so would entail. BTW, looking again at the patch I suggested in https://www.postgresql.org/message-id/10287.1485286334%40sss.pgh.pa.us it strikes me that the check logic was unnecessarily stupid. What we need to check is that there's not an odd number of backslashes at the end of the pattern. Since we know that backend encodings are ASCII-safe, the test logic could be changed to scan backwards, something like p += plen; nbackslash = 0; while (plen-- > 0) { if (*(--p) == '\\') nbackslash++; else break; } if (nbackslash & 1) ereport(ERROR, ...); For patterns of practical interest this would be of small and nearly constant cost. Maybe it is worth doing, especially since we've now had two independent complaints about it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: