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

HANDLER KEY > (x) does not work with DESC keys, Spider is affected and returns wrong results

Details

    Description

      create table t (a int, b char(1), primary key(a desc));
      insert into t VALUES (1,'f'),(2,'g'),(3,'j'), (4,'i'),(5,'h');
       
      handler t open;
      handler t read `PRIMARY` > (0);
       
      # Cleanup
      handler t close;
      drop table t;
      

      The read returns an empty result. With an ascending key it returns a row.

      It causes for example wrong results in Spider when it runs in handler mode.

      Example with Spider:

      install soname 'ha_spider';
       
      set spider_use_handler=3;
      set spider_same_server_link= 1;
       
      create table t (a int, b char(1), primary key(a desc));
      insert into t VALUES (1,'f'),(2,'g'),(3,'j'), (4,'i'),(5,'h');
       
      eval create server s foreign data wrapper mysql options 
      (host '127.0.0.1', database 'test', user 'root', port $MASTER_MYPORT);
       
      create table ts (a int, b char(1), primary key(a desc))
        engine=Spider COMMENT='wrapper "mysql", srv "s", table "t"';
       
      select a, b from ts where a > 0 and b = 'g' order by a;
      

      SELECT returns an empty result.
      If at least one of PK is not descending, the result is okay (`PRIMARY` > (0) is not used then in the resulting handler statement).

      Attachments

        Issue Links

          Activity

            First test case shows the correct behavior for HANDLER. Operator > means "read after key", it always reads a key entry after the specified one in the index order. For descending indexes it does not mean "greater than". There is no way to maintain intuitive "greater then" semantics when an index consists of key parts with a mix of different ordering, so the HANDLER statement always maps operators to the same exact low level index search commands. Independently from ordering of individual key parts.

            serg Sergei Golubchik added a comment - First test case shows the correct behavior for HANDLER . Operator > means "read after key", it always reads a key entry after the specified one in the index order. For descending indexes it does not mean "greater than". There is no way to maintain intuitive "greater then" semantics when an index consists of key parts with a mix of different ordering, so the HANDLER statement always maps operators to the same exact low level index search commands. Independently from ordering of individual key parts.

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              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.