Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: vectorized escapes LIKE '%\\%' incorrectly #68040

Closed
otan opened this issue Jul 25, 2021 · 1 comment · Fixed by #68289
Closed

sql: vectorized escapes LIKE '%\\%' incorrectly #68040

otan opened this issue Jul 25, 2021 · 1 comment · Fixed by #68289
Assignees
Labels
A-sql-vec SQL vectorized engine C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-queries SQL Queries Team

Comments

@otan
Copy link
Contributor

otan commented Jul 25, 2021

Describe the problem

LIKE '%\\%'

To Reproduce

This is a problem since v21.1, guessing since vectorize was on by default.

Setup:

 CREATE TABLE public.lookup_article (
      id SERIAL PRIMARY KEY,
      headline VARCHAR(100) NOT NULL,
      pub_date TIMESTAMPTZ NOT NULL,
      author_id INT8 NULL,
      slug VARCHAR(50) NULL
  );
  INSERT INTO "lookup_article" ("headline", "pub_date", "author_id", "slug") VALUES ('Article with \ backslash', '2005-11-22T00:00:00-06:00'::timestamptz, NULL, NULL) RETURNING "lookup_article"."id";

Now observe the difference in results when vectorized is off vs on:


[email protected]:26257/defaultdb> set vectorize=off;
SET


Time: 0ms total (execution 0ms / network 0ms)

[email protected]:26257/defaultdb> SELECT "lookup_article"."id", "lookup_article"."headline", "lookup_article"."pub_date", "lookup_article"."author_id", "lookup_article"."slug" FROM "lookup_article" WHERE "lookup_article"."headline" LIKE '%\\%';
          id         |         headline         |        pub_date        | author_id | slug
---------------------+--------------------------+------------------------+-----------+-------
  678626193848238081 | Article with \ backslash | 2005-11-22 06:00:00+00 |      NULL | NULL
(1 row)


Time: 1ms total (execution 1ms / network 0ms)

[email protected]:26257/defaultdb> set vectorize=on;
SET


Time: 0ms total (execution 0ms / network 0ms)

[email protected]:26257/defaultdb> SELECT "lookup_article"."id", "lookup_article"."headline", "lookup_article"."pub_date", "lookup_article"."author_id", "lookup_article"."slug" FROM "lookup_article" WHERE "lookup_article"."headline" LIKE '%\\%';
  id | headline | pub_date | author_id | slug
-----+----------+----------+-----------+-------
(0 rows)

The vectorize=off result is the expected result.

Found by #67974

@otan otan added C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. A-sql-vec SQL vectorized engine labels Jul 25, 2021
@blathers-crl blathers-crl bot added the T-sql-queries SQL Queries Team label Jul 25, 2021
@otan
Copy link
Contributor Author

otan commented Jul 25, 2021

cc @yuzefovich

@yuzefovich yuzefovich self-assigned this Jul 26, 2021
@otan otan changed the title sql: vectorized escapes LIKED %\\% incorrectly sql: vectorized escapes LIKE '%\\%' incorrectly Jul 26, 2021
timgraham added a commit to timgraham/django-cockroachdb that referenced this issue Jul 28, 2021
craig bot pushed a commit that referenced this issue Aug 2, 2021
68289: colexec: fix LIKE operators when patterns have escape characters r=yuzefovich a=yuzefovich

**colexec: fix LIKE operators when patterns have escape characters**

Fixes: #68040.

Release note (bug fix): Previously, CockroachDB could incorrectly
evaluate LIKE expressions when the pattern contained the escape
characters `\` if the expressions were executed via the vectorized
engine.

**colbuilder: force planning of optimized projection operators**

Whenever we're planning a projection expression, we have 3 cases: the
left is constant, the right is constants, and neither are constants. For
the second case we have some optimized operators. Previously, those
operators weren't exercised via the TestEval/vectorized because in the
eval tests the left side is constant. This commit switches the planning
to force planning of those optimized operators. This shouldn't really
have an effect on planning of actual queries.

This was prompted by the bug in LIKE operators that is fixed in the
previous commit. Had we forced the planning for our eval tests, we would
have caught it earlier.

This also revealed an incompatibility for our IN operator implementation when
the right side is an empty tuple which this commit also fixes. However,
I don't think this scenario can be hit in production because the
optimizer folds such an expression into correct `false`. Thus, there is
no release note.

Release note: None

Co-authored-by: Yahor Yuzefovich <[email protected]>
@craig craig bot closed this as completed in 9501adb Aug 2, 2021
@mgartner mgartner moved this to Done in SQL Queries Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sql-vec SQL vectorized engine C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-sql-queries SQL Queries Team
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants