Re: [BUGS] BUG #14512: Backslashes in LIKE - Mailing list pgsql-bugs

From Vojtěch Rylko
Subject Re: [BUGS] BUG #14512: Backslashes in LIKE
Date
Msg-id CA+fsJpFwe375OgNErLL0YyUOvXhOE8PppoYp29usg9vKxvA1kA@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14512: Backslashes in LIKE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [BUGS] BUG #14512: Backslashes in LIKE  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
2017-01-24 18:48 GMT+01:00 David G. Johnston <david.g.johnston@gmail.com>:
​Not a hacker but I'd say that the '\' LIKE '\\\' expression is encountering an invalid optimization that determines that the LIKE cannot succeed (due to string length differences, probably) - it too should fail like the other '\\' LIKE '\\\' example.

So, it is a "failure to fail" type of bug.  Confirmed using a 9.3.12 instance.

From user perspective I see this bug quite similar to behaviour of boolean expression evaluation, where it is stated in documentation:

if the result of an expression can be determined by evaluating only some parts of it, then other subexpressions might not be evaluated at all -- 4.2.14. Expression Evaluation Rules

So I expect this:

root=# select 1 where '\\' like '\\\';
ERROR:  LIKE pattern must not end with escape character
root=# select 1 where false and '\\' like '\\\';
 ?column? 
----------
(0 rows)

same as I expect 

root=# select 1 where 1/0 = 0 and false;
ERROR:  division by zero
root=# select 1 where false and 1/0 = 0;
 ?column? 
----------
(0 rows)

(Note that examples above are not deterministic because of unspecified order of subexpressions evaluation in where clause.)

But reported behaviour confuses me as it seems like leaked internals of LIKE implementation.

pgsql-bugs by date:

Previous
From: Vojtěch Rylko
Date:
Subject: Re: [BUGS] BUG #14512: Backslashes in LIKE
Next
From: Tomasz Szypowski
Date:
Subject: [BUGS] could not fork autovacuum worker process: No error