You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
By default, we should only expose functions/operators that are guaranteed to be compatible given a column's type details, namely:
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.
The text was updated successfully, but these errors were encountered: