[postgis-tickets] [PostGIS] #5361: Compound Curve inconsistent behavior with ST_GeometryN, ST_NumGeometries, and ST_Dump, add support for SQL MM ST_NumCurves and ST_CurveN

[PostGIS]

#5361: Compound Curve inconsistent behavior with ST_GeometryN, ST_NumGeometries,
and ST_Dump, add support for SQL MM ST_NumCurves and ST_CurveN
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  low      |  Milestone:  PostGIS 3.5.0
 Component:  postgis  |    Version:  master
Resolution:           |   Keywords:
----------------------+---------------------------
Comment (by pramsey):

 So, the offending piece of code is this one
 {{{
         /* call is valid on multi* geoms only */
         if (type==POINTTYPE     || type==LINETYPE    ||
 type==CIRCSTRINGTYPE ||
             type==COMPOUNDTYPE  || type==POLYGONTYPE ||
             type==CURVEPOLYTYPE || type==TRIANGLETYPE)

 }}}
 Both `COMPOUNDTYPE` and `CURVEPOLYTYPE` are, structurally, multi-
 geometries, so it would be easy to cast them to `COLLECTION` hand them
 off... then a CURVEPOLYGON would be handled like a nested
 GEOMETRYCOLLECTION... the rings would each be a COMPOUND and each of those
 would in turn be a set of CURVESTRING and/or LINESTRING.

 This seems... not entirely bad? And it does match the ST_Dump behaviour?
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5361#comment:5>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.