Hi, Alexey! On May 04, Alexey Botchkov wrote:
Hi, Sergei, guys.
This bug iis more like a feature of the HASH indexes. And i came upon other 'features' while experimenting.
Firstly the 'range' queries like HANDLER h READ `PRIMARY` < (5); cannot be naturally handled by the HASH keys. Only equality queries ...'PRIMARY' = (5); make sence. And these 'range' queries just return wrong empty result. I'd say we need to fire an error in this case. Do you agree?
Yes. Like "HASH index `PRIMARY` does not support this operation" ?
Second problem - the SYSTEM VERSIONING. It adds an extra column to the key, which makes this key virtually useless. I think for the VERSIONING we should either replace the HASH key with the RBTREE, or get the row_end data from the table after getting records from the HASH. What is your idea how to deal with this?
row_end must be a part of every unique key, because uniqueness of current data should not be affected by historical, deleted, rows. In this particular use case, HANDLER is a low level command, it doesn't see high-level features like versioning. So, for HANDLER row_end is just a normal key part, should be used as HANDLER h READ `PRIMARY` = (5, '2038-01-19 03:14:07.999999'); Regards, Sergei Chief Architect MariaDB and security@mariadb.org