Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-3930

Spatial functions: Return error instead of NULL for non supported geometry types

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Won't Fix
    • 5.5.28a
    • N/A
    • GIS
    • 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

          Activity

            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.

            serg Sergei Golubchik added a comment - 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.

            People

              Unassigned Unassigned
              georg Georg Richter
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.