Hi Calcite community, We would like to discuss adding GEOGRAPHY as a first-class SQL and relational type in Calcite, distinct from the existing GEOMETRY type.
This follows the discussion about native GEOGRAPHY support in Flink [1], motivated in part by interoperability with Iceberg geography columns. Participants raised concerns about maintaining a Flink-only planner type, handling validation and type-system edge cases, and eventually migrating to an upstream Calcite type. We would like to address these concerns through a Calcite contribution. Our proposal is available here [2]. The proposed first change covers parsing, validation, relational type propagation, and unparsing, including nullability, type coercion rules, nested types, and SQL/Rel round trips. A separate type family would preserve the distinction between geographic and planar values and prevent existing GEOMETRY functions from accepting GEOGRAPHY operands unintentionally. The initial type would be unparameterized and independent of a particular runtime representation. The proposal leaves CRS/SRID metadata, encoding, and runtime execution to consuming engines and adapters. It does not introduce spatial functions, constructors, serialization/deserialization, or storage-format mappings. We also want to build on the Sedona discussion. Jia clarified that SedonaFlink already supports Geography through RAW with a dedicated serializer, and called for joint consideration of CRS/SRID, spherical-edge semantics, validation, equality, and shared serialization. The limited Calcite scope proposed here is intended as a first step; it does not settle those broader interoperability choices or assume that Sedona would adopt a particular runtime representation. We would appreciate feedback on two main questions: 1. Should Calcite expose an unparameterized, representation-neutral GEOGRAPHY type distinct from GEOMETRY? 2. Is the proposed parser/validator/type-system scope sufficient for a first contribution without constructors or a Calcite runtime value class? In considering these questions, we would particularly welcome feedback on the proposed semantic boundary: same-type equality is permitted with adapter-defined execution semantics, ordering is rejected, and CRS/SRID is not encoded in the Calcite type. Are additional guarantees needed at the planner level? Subject to Calcite review and acceptance, the intended integration path is to merge the necessary support upstream, then bring those changes into Flink, with any temporary copies removed when Flink upgrades its Calcite dependency. We would also welcome suggestions for regression cases, particularly around null handling, nested types, and type-to-SQL conversion. The Flink dev list and Jia are copied to help coordinate the discussion. Thank you for your feedback. Best regards, David [1] Flink GEOGRAPHY discussion <https://lists.apache.org/thread/flbj8dfdfgs26klrxt7xch3r9785ky67> [2] Planner-level GEOGRAPHY type in Apache Calcite proposal <https://docs.google.com/document/d/1Btqd0oZT8ctqIaGI_AROyAFJQe68RsVyeQbtmK4wHQw/edit>
