Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.8(EOL)
-
None
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
- is caused by
-
MDEV-13756 Implement descending index: KEY (a DESC, b ASC)
-
- Closed
-
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.