According to the OpenGIS specifications for SQL, geometry sub-types like POINT, LINESTRING, etc. are separate data types. Having separate type handlers Type_handler_point, Type_handler_linestring, etc (instead of a single Type_handler_geometry with a geometry type attribute) will look more natural in the code:
- It will be easier to turn Type_handler_geometry into a plugin, e.g. in the parser. The geometry specific fields in %union in sql_yacc.yy, such as geom_type, will be removed.
- Better error reporting, e.g. precise data type instead of GEOMETRY:
- It will make implementing
MDEV-17832easier (with a cleaner API).
- It will allow to localize geometry specific things inside Type_handler_geometry, e.g.
- move enum geometry_type from Field to Type_handler_geometry
- remove Item::geometry_type() and Item::set_geometry_type()
To remove geometry specific tests, such as f_is_geom(), from the loop handling keys in mysql_prepare_create_table(), and to simplify adding new data typesr, lets add a few virtual methods:
With these new methods, data type plugins will be able to decide how to handle various key types.
This also will help to move POINT specific global declaration from sql_table.h inside Type_handler_point:
Let's also add separate classes under Item_func_spatial_collection for all constructor-alike SQL functions, so the hierarchy looks like this:
In the future, it will allow to remove geometry-specific code in the grammar, e.g.:
In a separate MDEV later we'll replace it to something like this: