From: | Vojtěch Rylko <vojta(dot)rylko(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14512: Backslashes in LIKE |
Date: | 2017-01-25 09:28:25 |
Message-ID: | CA+fsJpFwe375OgNErLL0YyUOvXhOE8PppoYp29usg9vKxvA1kA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
2017-01-24 18:48 GMT+01:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomasz Szypowski | 2017-01-25 12:46:01 | could not fork autovacuum worker process: No error |
Previous Message | Vojtěch Rylko | 2017-01-25 09:16:58 | Re: BUG #14512: Backslashes in LIKE |