james-willis opened a new issue, #3263: URL: https://github.com/apache/sedona/issues/3263
## Expected behavior Using the legacy alias function names `ST_Force_2D` and `ST_Force3DZ` should warn users that a canonical name exists (`ST_Force2D` and `ST_Force3D` respectively), so new SQL stops accumulating on the alias names and they can eventually be removed. ## Actual behavior The aliases are registered as first-class functions with no indication anywhere (runtime, API, or docs) that the canonical names are preferred. Other engines (e.g. sedona-db) then face pressure to replicate alias-for-alias parity: see the discussion on apache/sedona-db#1162, where adding `st_force_2d`/`st_force3dz` parity was reviewed and deprecating the Sedona aliases (with a warning giving the canonical name) was suggested instead, since removing them outright would break existing production SQL. ## Proposal Deprecate the two alias names on the Spark surface without changing behavior: - one-time-per-JVM runtime warning when the alias is used (the only channel that reaches SQL users) - `@deprecated` on the Scala DataFrame API methods - `DeprecationWarning` in the Python API functions - documentation marked accordingly Note on `ST_Force3DZ`: unlike `ST_Force_2D` (a pre-2.1 PostGIS name that PostGIS itself deprecated), `ST_Force3DZ` is the canonical name in current PostGIS (`ST_Force3D` is its alias there). Deprecating it trades PostGIS name-compatibility for having a single canonical name in Sedona — flagged for discussion on the PR. Flink and Snowflake register the same alias names; those surfaces can follow up separately if this direction is accepted. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
