Re: BUG #18765: Inconsistent behaviour and errors with LIKE
От | Tom Lane |
---|---|
Тема | Re: BUG #18765: Inconsistent behaviour and errors with LIKE |
Дата | |
Msg-id | 1693904.1736370752@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18765: Inconsistent behaviour and errors with LIKE (Peter Eisentraut <peter@eisentraut.org>) |
Список | pgsql-bugs |
Peter Eisentraut <peter@eisentraut.org> writes: > I have also come across this issue recently, and I think we should > actually fix it. It makes sense to verify that the pattern is > syntactically correct before trying to use it, instead of just using it > incrementally and then erroring when you happen to hit the problematic bits. I'm concerned about the performance cost of adding an extra scan of the pattern --- a scan that has exactly zero benefit in all normal use cases. Admittedly typical patterns aren't very big, but still the cost/benefit ratio is bad for most people. I wonder if we could buy back whatever it'd cost us by treating this initial scan as a "compilation" of the LIKE pattern into some form that would make the actual string search cheaper. My gut says that building a representation that contains tokens like "any character", "zero or more any characters", or "literal string of N bytes" could save some cycles while searching. In ILIKE, we could perhaps also case-fold the pattern at this stage. regards, tom lane
В списке pgsql-bugs по дате отправления: