Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8222

"string_field LIKE int_const" returns a wrong result in case of UCS2

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.5(EOL), 10.0(EOL), 10.1(EOL)
    • 10.1.5
    • Character Sets
    • None

    Description

      This script:

      DROP TABLE IF EXISTS t1;
      CREATE TABLE t1 (a VARCHAR(10) CHARSET utf8);
      INSERT INTO t1 VALUES ('1');
      SELECT * FROM t1 WHERE a LIKE 1;

      correctly returns one row:

      +------+
      | a    |
      +------+
      | 1    |
      +------+

      If I change character set from utf8 to ucs2, it returns empty set:

      DROP TABLE IF EXISTS t1;
      CREATE TABLE t1 (a VARCHAR(10) CHARSET ucs2);
      INSERT INTO t1 VALUES ('1');
      SELECT * FROM t1 WHERE a LIKE 1;

      The problem happens in this piece of the code:

      bool Item_func::setup_args_and_comparator(THD *thd, Arg_comparator *cmp)
      {
        DBUG_ASSERT(arg_count == 2);
       
        if (args[0]->cmp_type() == STRING_RESULT &&
            args[1]->cmp_type() == STRING_RESULT &&
            agg_arg_charsets_for_comparison(cmp->cmp_collation, args, 2))
            return true;

      In case of LIKE it should unconditionally call arg_arg_charsets_for_comparison(), no matter that cmp_type() of the arguments are.

      Attachments

        Activity

          bar Alexander Barkov created issue -
          bar Alexander Barkov made changes -
          Field Original Value New Value
          Description This script:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET utf8);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}
          correctly returns one row:
          {noformat}
          +------+
          | a |
          +------+
          | 1 |
          +------+
          {noformat}

          If I change character set from utf8 to ucs2, it returns empty set:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET ucs2);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}
          This script:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET utf8);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}
          correctly returns one row:
          {noformat}
          +------+
          | a |
          +------+
          | 1 |
          +------+
          {noformat}

          If I change character set from utf8 to ucs2, it returns empty set:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET ucs2);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}


          The problem happens in this piece of the code:
          {code}
          bool Item_func::setup_args_and_comparator(THD *thd, Arg_comparator *cmp)
          {
            DBUG_ASSERT(arg_count == 2);

            if (args[0]->cmp_type() == STRING_RESULT &&
                args[1]->cmp_type() == STRING_RESULT &&
                agg_arg_charsets_for_comparison(cmp->cmp_collation, args, 2))
                return true;
          {code}

          In case of LIKE it should unconditionally call arg"_arg_charsets_for_comparison(), no matter that cmp_type() of the arguments are.
          bar Alexander Barkov made changes -
          Description This script:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET utf8);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}
          correctly returns one row:
          {noformat}
          +------+
          | a |
          +------+
          | 1 |
          +------+
          {noformat}

          If I change character set from utf8 to ucs2, it returns empty set:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET ucs2);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}


          The problem happens in this piece of the code:
          {code}
          bool Item_func::setup_args_and_comparator(THD *thd, Arg_comparator *cmp)
          {
            DBUG_ASSERT(arg_count == 2);

            if (args[0]->cmp_type() == STRING_RESULT &&
                args[1]->cmp_type() == STRING_RESULT &&
                agg_arg_charsets_for_comparison(cmp->cmp_collation, args, 2))
                return true;
          {code}

          In case of LIKE it should unconditionally call arg"_arg_charsets_for_comparison(), no matter that cmp_type() of the arguments are.
          This script:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET utf8);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}
          correctly returns one row:
          {noformat}
          +------+
          | a |
          +------+
          | 1 |
          +------+
          {noformat}

          If I change character set from utf8 to ucs2, it returns empty set:
          {code}
          DROP TABLE IF EXISTS t1;
          CREATE TABLE t1 (a VARCHAR(10) CHARSET ucs2);
          INSERT INTO t1 VALUES ('1');
          SELECT * FROM t1 WHERE a LIKE 1;
          {code}


          The problem happens in this piece of the code:
          {code}
          bool Item_func::setup_args_and_comparator(THD *thd, Arg_comparator *cmp)
          {
            DBUG_ASSERT(arg_count == 2);

            if (args[0]->cmp_type() == STRING_RESULT &&
                args[1]->cmp_type() == STRING_RESULT &&
                agg_arg_charsets_for_comparison(cmp->cmp_collation, args, 2))
                return true;
          {code}

          In case of LIKE it should unconditionally call arg_arg_charsets_for_comparison(), no matter that cmp_type() of the arguments are.
          bar Alexander Barkov made changes -
          Fix Version/s 10.1.5 [ 18813 ]
          Fix Version/s 10.1 [ 16100 ]
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 67706 ] MariaDB v4 [ 149209 ]

          People

            bar Alexander Barkov
            bar Alexander Barkov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.