Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose only compatible functions/operators #2

Open
mattbretl opened this issue Apr 4, 2019 · 0 comments
Open

Expose only compatible functions/operators #2

mattbretl opened this issue Apr 4, 2019 · 0 comments

Comments

@mattbretl
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant