RFC: Drop PostGIS compatibility (remove PROJ and GEOS libraries)

[iliana]

CockroachDB uses PROJ and GEOS to provide spatial functions, intended to be compatible with PostGIS 3.0.1. PostGIS is commonly used enough among PostgreSQL users that it is warranted for CockroachDB to include built-in support for it. Oxide does not use any of the spatial functions in our product, and building these libraries seems to pose a reasonable risk to our continued ability to maintain this version of CockroachDB:

• Tests for spatial functions compare floating point values bit-for-bit. Trying to run the tests after upgrading from GEOS 3.8 to 3.9, or even simply running the tests on an arm64 system, fails a number of spatial function tests. It's unclear whether it's worth trying to update these tests or make them more logically reasonable. (Some of these tests are comparing bits at the PostgreSQL protocol level, so it may be impractical to make them more logically reasonable.)
• PROJ has completely redone its APIs in more recent versions. Upgrading the interface between Go and the PROJ library for this API change is not trivial.
• A significant amount of the build system's complexity comes from needing to build libraries outside of the Go ecosystem such as PROJ and GEOS. Removing support for spatial functions that require PROJ/GEOS will significantly reduce the cognitive load of maintaining these builds.

On the other hand:

• The current versions do (currently) build successfully on all platforms. The primary risk is if future changes to system libraries, headers, and toolchains on Helios, macOS, or Ubuntu break the build process.
• While having these tests work correctly would be nice for darwin-arm64 (as that will generally be the macOS build target available to us in the limit), we don't run the tests in CI today and it's not necessary for our use case.

Oxide does not use any of the spatial functions in our product today. It's unclear whether there will be any external users of this fork, or whether they will be using spatial functions. I'm opening this issue to organize discussion about this at Oxide but also welcome any external users to let us know if they 1) exist and 2) want PostGIS compatibility.

[hawkw]

I would certainly be extremely surprised¹ if the Oxide control plane use case ever needed PostGIS support...

If it currently builds, though, it seems like one option here might be to keep building it, but solving any non-trivial issues with keeping it building by just ripping the whole thing out?

Footnotes

1. But, anything is possible! ↩

[andrewjstone]

This certainly seems reasonable to me.

[iliana]

If it currently builds, though, it seems like one option here might be to keep building it, but solving any non-trivial issues with keeping it building by just ripping the whole thing out?

The build system is fairly fragile. I definitely understand why when faced with the current Makefile they decided Bazel was a lesser evil, and I think that the build system itself is a tangible risk separate from "oh no, these C++ libraries don't build anymore" that's a lot harder to simplify if PROJ and GEOS builds remain part of it.

[fire]

Should we make a separate rfc for the build system?