Description
By default, we should only expose functions/operators that are guaranteed to be compatible given a column's type details, namely:
- base type: geography, geometry
- subtype: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPoint, GeometryCollection
- hasZ: true/false
- hasM: true/false
This plugin already accounts for the base type (geography columns have a restricted set of functions/operators compared to geometry columns), but we should consider the subtype/z/m as well. The column type details are introspected and exposed via the @graphile/postgis plugin, so we should already have what we need on that front.
The next step is to put together a spec describing which types are compatible with each function/operator. This may (and should!) already exist somewhere, but I haven't found a single resource that covers everything. Section 14.11 of the PostGIS docs (https://postgis.net/docs/PostGIS_Special_Functions_Index.html) comes close, but doesn't address the subtype issue.
As one example, the ST_Contains page of the docs (https://postgis.net/docs/manual-2.5/ST_Contains.html) calls out the GeometryCollection subtype as being incompatible, so we shouldn't expose a contains operator field in that case.
As another example, we shouldn't expose 3D functions/operators on 2D columns.
Once this is ready to merge, we can add plugin options (or smart comments) for users to opt-in to "unsafe" functions/operators, to handle cases where column constraints can't be added.