Bug #30825: Problems when putting a non-spatial index on a GIS column

 Fixed the usage of spatial data (and Point in specific) with 
 non-spatial indexes.
 Several problems :
   - The length of the Point class was not updated to include the 
     spatial reference system identifier. Fixed by increasing with 4 
     bytes.
   - The storage length of the spatial columns was not accounting for
     the length that is prepended to it. Fixed by treating the 
     spatial data columns as blobs (and thus increasing the storage
     length)
   - When creating the key image for comparison in index read wrong
     key image was created (the one needed for and r-tree search,
     not the one for b-tree/other search). Fixed by treating the
     spatial data columns as blobs (and creating the correct kind of
     image based on the index type). 


mysql-test/r/bdb_gis.result:
  Bug #30825: bdb tests
mysql-test/r/gis-rtree.result:
  Bug #30825: key length changed
mysql-test/r/gis.result:
  Bug #30825: MyISAM tests
mysql-test/r/innodb_gis.result:
  Bug #30825: InnoDB tests
mysql-test/t/bdb_gis.test:
  Bug #30825: bdb tests
mysql-test/t/gis.test:
  Bug #30825: MyISAM tests
mysql-test/t/innodb_gis.test:
  Bug #30825: InnoDB tests
sql/field.cc:
  Bug #30825: Removed Field_geom::get_key_image as Field_blog::get_key_image 
    takes type parameter into consideration and is a superset of 
    Field_geom::get_key_image()
sql/field.h:
  Bug #30825: Removed Field_geom::get_key_image as Field_blog::get_key_image 
    takes type parameter into consideration and is a superset of 
    Field_geom::get_key_image()
sql/sql_select.h:
  Bug #30825: Geometry data are a blob derivate
sql/sql_table.cc:
  Bug #30825: Increased key length to accomodate for
    spatial reference system identifier (srid)
sql/sql_yacc.yy:
  Bug #30825: Increased key length to accomodate for
    spatial reference system identifier (srid)
sql/table.cc:
  Bug #30825: It stores a length for spatial data
   as well, so increase the storage length (as it's
   done for blobs).
mysql-test/include/gis_keys.inc:
  Bug #30825: Test file for spatial data and non-spatial indexes

1 files changed, 46 insertions, 0 deletions

diff --git a/mysql-test/include/gis_keys.inc b/mysql-test/include/gis_keys.inc
new file mode 100644
index 00000000000..295e0c48234
--- /dev/null
+++ b/mysql-test/include/gis_keys.inc
@@ -0,0 +1,46 @@
+--source include/have_geometry.inc
+
+#
+# Spatial objects with keys
+#
+
+#
+# Bug #30825: Problems when putting a non-spatial index on a GIS column
+#
+
+CREATE TABLE t1 (p POINT);
+CREATE TABLE t2 (p POINT, INDEX(p));
+INSERT INTO t1 VALUES (POINTFROMTEXT('POINT(1 2)'));
+INSERT INTO t2 VALUES (POINTFROMTEXT('POINT(1 2)'));
+
+-- no index, returns 1 as expected
+SELECT COUNT(*) FROM t1 WHERE p=POINTFROMTEXT('POINT(1 2)');
+
+-- with index, returns 1 as expected
+-- EXPLAIN shows that the index is not used though
+-- due to the "most rows covered anyway, so a scan is more effective" rule
+EXPLAIN 
+SELECT COUNT(*) FROM t2 WHERE p=POINTFROMTEXT('POINT(1 2)');
+SELECT COUNT(*) FROM t2 WHERE p=POINTFROMTEXT('POINT(1 2)');
+
+-- adding another row to the table so that
+-- the "most rows covered" rule doesn't kick in anymore
+-- now EXPLAIN shows the index used on the table
+-- and we're getting the wrong result again
+INSERT INTO t1 VALUES (POINTFROMTEXT('POINT(1 2)'));
+INSERT INTO t2 VALUES (POINTFROMTEXT('POINT(1 2)'));
+EXPLAIN 
+SELECT COUNT(*) FROM t1 WHERE p=POINTFROMTEXT('POINT(1 2)');
+SELECT COUNT(*) FROM t1 WHERE p=POINTFROMTEXT('POINT(1 2)');
+
+EXPLAIN 
+SELECT COUNT(*) FROM t2 WHERE p=POINTFROMTEXT('POINT(1 2)');
+SELECT COUNT(*) FROM t2 WHERE p=POINTFROMTEXT('POINT(1 2)');
+
+EXPLAIN 
+SELECT COUNT(*) FROM t2 IGNORE INDEX(p) WHERE p=POINTFROMTEXT('POINT(1 2)');
+SELECT COUNT(*) FROM t2 IGNORE INDEX(p) WHERE p=POINTFROMTEXT('POINT(1 2)');
+
+DROP TABLE t1, t2;
+
+--echo End of 5.0 tests