Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
5.5.28a
-
None
Description
This issue might be related to MDEV-3819.
Geometry functions should be more restrictive and produce an error in case parameter is a valid geometry but has the wrong type.
According to the OGC standard definition the return value for a
function is NULL if the geometry is NULL (RETURNS NULL ON NULL).
The standard also defines the valid geometry types for functions:
7.2.9 SQL routines on type POINT
The SQL/MM ST_X, ST_Y, ST_Z and ST_M routines and all routines supported by type GEOMETRY shall be supported for geometries of type Point.
Example:
PostGIS
osm=# select st_x(GeomFromText('LINESTRING(1 1, 2 2)'));
|
ERROR: Argument to X() must be a point
|
MariaDB
mysql> select st_x(GeomFromText('LINESTRING(1 1, 2 2)'));
|
+--------------------------------------------+
|
| st_x(GeomFromText('LINESTRING(1 1, 2 2)')) |
|
+--------------------------------------------+
|
| NULL |
|
+--------------------------------------------+
|
1 row in set (0.06 sec)
|
Affected functions (might be incomplete)
Geometry type POINT
- ST_X()
- ST_Y()
- ST_Z() (not implemented yet)
Geometry type CURVE (includes LINESTRING, LINE, LINEARRING)
- ST_StartPoint()
- ST_EndPoint()
- ST_IsRing()
- ST_Length()
Geometry type LINESTRING
- ST_NumPoints()
- ST_PointN()
Geometry type SURFACE (includes POLYGON, POLYHEDRALSURFACE)
- ST_Centroid()
- ST_Area()
- ST_PointOnSurface()
Geometry type POLYGON
- ST_ExteriorRing()
- ST_InteriorRingN()
- ST_NumInteriorRing()
Attachments
Issue Links
- relates to
-
MDEV-3819 missing constraints for spatial column types
-
- Closed
-
Historically MariaDB often uses more relaxed rules than the standards dictate.
This behavior in particular was in MariaDB forever, since the very first MariaDB version. While it can be changed to be more OGC standard compliant, it'll be an incompatible change in behavior that will likely break some user applications. That is, if we'll do it, there must be a way for users to switch to the old behavior. This is usually done via sql_mode.
Adding a new sql_mode shouldn't be done lightly, and considering that this is really a low profile issue, that didn't attract any user attention in 12 years, it's likely not worth a new sql_mode.