[MDEV-19923] Add type handlers for geometry sub-types - Jira

Alexander Barkov created issue - 2019-07-02 06:37

Alexander Barkov made changes - 2019-07-02 06:37

Field	Original Value	New Value
Rank		Ranked higher

Alexander Barkov made changes - 2019-07-02 06:42

Link

This issue blocks ~~MDEV-4912~~ [ ~~MDEV-4912~~ ]

Alexander Barkov made changes - 2019-07-02 06:42

Link

This issue blocks ~~MDEV-17832~~ [ ~~MDEV-17832~~ ]

Alexander Barkov made changes - 2019-07-02 06:43

Description

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.
- More precise error reporting (e.g. precise data type instead of GEOMETRY:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (with a cleaner API).
- It will allow to localize geometry specific things inside Type_handler_geometry.

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.
- More precise error reporting (e.g. precise data type instead of GEOMETRY:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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.

Alexander Barkov made changes - 2019-07-02 06:43

Description

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.
- More precise error reporting (e.g. precise data type instead of GEOMETRY:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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.

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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.

Alexander Barkov made changes - 2019-07-02 06:53

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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.

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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().

Alexander Barkov made changes - 2019-07-02 06:54

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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().

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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().

Alexander Barkov made changes - 2019-07-02 06:54

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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().

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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()

Alexander Barkov made changes - 2019-07-02 06:54

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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()

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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 types easier, lets add a few virtual methods:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
With these new methods, data type plugins will be able to decide how to handle various key types.

Alexander Barkov made changes - 2019-07-02 06:54

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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 types easier, lets add a few virtual methods:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
With these new methods, data type plugins will be able to decide how to handle various key types.

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
With these new methods, data type plugins will be able to decide how to handle various key types.

Alexander Barkov made changes - 2019-07-02 07:09

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
With these new methods, data type plugins will be able to decide how to handle various key types.

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
With these new methods, data type plugins will be able to decide how to handle various key types.

Let's also add separate classes under Item_func_spatial_collection for all constructor-alike SQL functions, so the hierarchy looks like this:

{noformat}
    Item_func_spatial_collection
      Item_func_geometrycollection
      Item_func_linestring
      Item_func_polygon
      Item_func_multilinestring
      Item_func_multipoint
      Item_func_multipolygon
{noformat}

In the future, it will allow to remove geometry-specific code in the grammar, e.g.:
{code:cpp}
       | GEOMETRYCOLLECTION '(' expr_list ')'
         {
           $$= GEOM_NEW(thd,
                        Item_func_spatial_collection(thd, *$3,
                        Geometry::wkb_geometrycollection,
                        Geometry::wkb_point));
           $$= GEOM_NEW(thd, Item_func_geometrycollection(thd, *$3));
         }
{code}
In a separate MDEV later we'll replace it to something like this:
{code:cpp}
       | user_defined_type_handler_name '(' expr_list ')'
         {
           if (!($$= $1->make_constructor_item($3))
             MYSQL_YYABORT;
         }
{code}

Alexander Barkov made changes - 2019-07-02 07:17

Link

This issue is blocked by ~~MDEV-19908~~ [ ~~MDEV-19908~~ ]

Alexander Barkov made changes - 2019-07-02 12:13

Description

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
With these new methods, data type plugins will be able to decide how to handle various key types.

Let's also add separate classes under Item_func_spatial_collection for all constructor-alike SQL functions, so the hierarchy looks like this:

{noformat}
    Item_func_spatial_collection
      Item_func_geometrycollection
      Item_func_linestring
      Item_func_polygon
      Item_func_multilinestring
      Item_func_multipoint
      Item_func_multipolygon
{noformat}

In the future, it will allow to remove geometry-specific code in the grammar, e.g.:
{code:cpp}
       | GEOMETRYCOLLECTION '(' expr_list ')'
         {
           $$= GEOM_NEW(thd,
                        Item_func_spatial_collection(thd, *$3,
                        Geometry::wkb_geometrycollection,
                        Geometry::wkb_point));
           $$= GEOM_NEW(thd, Item_func_geometrycollection(thd, *$3));
         }
{code}
In a separate MDEV later we'll replace it to something like this:
{code:cpp}
       | user_defined_type_handler_name '(' expr_list ')'
         {
           if (!($$= $1->make_constructor_item($3))
             MYSQL_YYABORT;
         }
{code}

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:
{code:sql}
SELECT POINT(0,0)+POINT(0,0);
ERROR HY000: Illegal parameter data types point and point for operation '+'
{code}
- It will make implementing ~~MDEV-17832~~ easier (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:

{code:sql}
virtual bool Key_part_spec_init_primary(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_unique(Key_part_spec *part,
                                       const Column_definition &def,
                                       const handler *file,
                                       bool *has_key_needed) const;
virtual bool Key_part_spec_init_multiple(Key_part_spec *part,
                                         const Column_definition &def,
                                         const handler *file) const;
virtual bool Key_part_spec_init_foreign(Key_part_spec *part,
                                        const Column_definition &def,
                                        const handler *file) const;
virtual bool Key_part_spec_init_spatial(Key_part_spec *part,
                                        const Column_definition &def) const;
{code}
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:
{code:cpp}
/* Maximum length of GEOM_POINT Field */
#define MAX_LEN_GEOM_POINT_FIELD 25
{code}

Let's also add separate classes under Item_func_spatial_collection for all constructor-alike SQL functions, so the hierarchy looks like this:

{noformat}
    Item_func_spatial_collection
      Item_func_geometrycollection
      Item_func_linestring
      Item_func_polygon
      Item_func_multilinestring
      Item_func_multipoint
      Item_func_multipolygon
{noformat}

In the future, it will allow to remove geometry-specific code in the grammar, e.g.:
{code:cpp}
       | GEOMETRYCOLLECTION '(' expr_list ')'
         {
           $$= GEOM_NEW(thd,
                        Item_func_spatial_collection(thd, *$3,
                        Geometry::wkb_geometrycollection,
                        Geometry::wkb_point));
           $$= GEOM_NEW(thd, Item_func_geometrycollection(thd, *$3));
         }
{code}
In a separate MDEV later we'll replace it to something like this:
{code:cpp}
       | user_defined_type_handler_name '(' expr_list ')'
         {
           if (!($$= $1->make_constructor_item($3))
             MYSQL_YYABORT;
         }
{code}

Alexander Barkov made changes - 2019-07-03 11:59

issue.field.resolutiondate

2019-07-03 11:59:57.0

2019-07-03 11:59:57.252

Alexander Barkov made changes - 2019-07-03 11:59

Fix Version/s		10.5.0 [ 23709 ]
Fix Version/s	10.5 [ 23123 ]
Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Alexander Barkov made changes - 2019-07-03 18:57

Link

This issue relates to ~~MDEV-19944~~ [ ~~MDEV-19944~~ ]

Sergei Golubchik made changes - 2021-12-06 21:24

Workflow

MariaDB v3 [ 97920 ]

MariaDB v4 [ 134022 ]

MariaDB Server

Add type handlers for geometry sub-types

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration