[postgis-tickets] [PostGIS] #4302: ST_MemSize for geography

[PostGIS]

#4302: ST_MemSize for geography
-----------------------+---------------------------
  Reporter:  ezimanyi  |      Owner:  pramsey
      Type:  defect    |     Status:  reopened
  Priority:  medium    |  Milestone:  PostGIS 2.5.2
 Component:  postgis   |    Version:  2.4.x
Resolution:            |   Keywords:
-----------------------+---------------------------

Comment (by pramsey):

 There's hundreds of "geometry-only" functions, and we made the decision
 when bringing in geography not to duplicate them all. All the format
 outputs, all the geometry dumping and forming functions, on and on and on.
 I certainly see no reason to privilege memsize as an exception to that
 "rule". The only functions I feel should be geography are ones where
 there's something specifically different about their behaviour, ones where
 the great-circles and on-a-sphere nature of geography actually results in
 different answers.

 Is geography a first class citizen? Not entirely, as its implementations
 are all (a) slower and (b) more brittle than geography. So we support it?
 As far as we can, knowing that there's a huge ocean of terrible robustness
 and failure cases hiding there, and that the performance issues of
 spherical geometry can bite new users hard.

 There was a hard question to answer when starting geodetic support, given
 that we weren't going to release with even a fraction of the functional
 coverage of geometry. We would have indexes, we would have distance. That
 was about it. That's still about it. We've added area. There's no DE9IM
 relationships, there's no constructive geometry (union, buffer,
 intersection, difference), there's certainly none of the fancier crazy
 things like linear referencing, or handling of 3D. So the question was, do
 we have geography functions for the two "true" geography functions, and
 then do 100 other bindings for functions that don't really care about the
 spherical earth model. Or just do bindings for the functions that are
 actually backed by geography logic?

 Anyways, that's the story. The silly dig ("should we remove...") was not
 necessary, I think.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4302#comment:6>
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.