ST_MemSize for geography

[ezimanyi]

It would we nice to have the function integer ST_MemSize(geometry geomA); also available for geographies. I would be very easy to add support for it, just need to add the SQL definition and use the same C function for both geometry and geography.

[pramsey]

That's true of a vast number of functions… is there any reason you cannot just cast? They share the same memory footprint.

[ezimanyi]

Yes, it is possible to cast, but that makes geography a second-class citizen wrt geometry

[pramsey]

That's not a coincidence.

[komzpa]

I was the one directing Esteban to open this ticket so I reopen it.

Paul, can you elaborate on "That's not a coincidence."?

Is geography not a first class citizen?

(Should we remove geography altogether from PostGIS then, if we're not going to support it?)

(Esteban, can you provide a simple pull request if it's a simple addition?)

[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.

[komzpa]

Talking about "remove geography". MySQL implements it inside geometry datatype, choosing implementation solely by SRID. This way they don't have a problem with "second class citizen", and API looks cleaner.

​https://mysqlserverteam.com/geography-in-mysql-8-0/

[robe]

I'm closing this as a wontfix. Of all the functions we could possibly choose to support for geography, ST_Memsize is up there in the dumbest category.

That said geography is a second class citizen because it came second and we purposely DID not just wrap it in geometry because

a) 4326 would then be slow in geometry and often times people just don't care planar even for 4326 is often good enough

b) We had toyed with autocasts so that geography would just autocast itself to use geometry functions where it could. We took that out because it caused too many ambiguous function this and that when people toyed with using 'POLYGON(….)' and also when it did autocast, it was ahocking surprise in many cases.

We still have a bit of a shocking surprise that geometry autocasts to geography as in the case with the stupid hack people use of ST_Distance(geometry, true)

c) Adding a native geography function for every geometry would balloon our list of function 300 more and would be a huge pain to maintain.