Is there actually a requirement to overload? The function could check at runtime whether it has a GEOMETRY or GEOGRAPHY value.
> On Nov 3, 2026, at 10:54 AM, Jerome Haltom <[email protected]> wrote: > > It has been a couple months since I had thought through this, but I think the > downside of my approach was there was no way to overload functions in a way > that made sense. I don't think you could overload by constraint. > > So, so you couldn't validate. Which most engines do. > > ________________________________ > From: Julian Hyde <[email protected]> > Sent: Tuesday, November 03, 2026 12:11 > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Planner-level GEOGRAPHY type in Apache Calcite > > There are a lot of geospatial functions. Would the functions that currently > take GEOMETRY also be applicable to GEOGRAPHY? Do we need additional > functions for the GEOGRAPHY type? > > Is GEOGRAPHY a subtype if GEOMETRY (in the sense that a GEOGRAPHY value can > be used as an argument to a function with a GEOMETRY parameter? > > I worry about this change creating a lot of new code (possibly copy-pasted > from existing code, possibly generated by agents, but nevertheless requiring > maintenance). Give me a sense of the amount of new code that would be > required, and which components it would reside in. > > I wonder whether GEOGRAPHY could be a GEOMETRY type with a constraint “srid > IS NOT NULL”. We cannot currently attach constraints to types (except the > constraints that are represented as type parameters, e.g. VARCHAR(10) is “a > string whose length is not greater than 10”). Is a constrained GEOMETRY type > the right way to think of this? If so, attaching constraints to types might > be a way to reduce the amount of code that has to be written. > > (I had a similar thought about constraints and types when we had the > discussion about the VECTOR type. I still believe that the VECTOR type is > basically an ARRAY type where the length is a constant. My work on Morel, and > its elegant type system based on Standard ML’s modules and functors, makes me > think about how we remove/reduce code by improving our type system.) > > Julian > > >> On Nov 3, 2026, at 8:24 AM, Jerome Haltom <[email protected]> wrote: >> >> I approve of this, as it would let me deprecate my existing geography-like >> support. >> >> https://github.com/ikvmnet/calcite-dotnet/tree/main/src/Apache.Calcite.Geography >> >> This will be weird for you guys, since it's .NET code. But it's an attempt >> at a full suite of Geography functions across the existing geometry types. >> It is only WGS84 however. It uses S2 and >> net.sf.geographiclib:GeographicLib-Java >> >> >> >> ________________________________ >> From: David Chaava via dev <[email protected]> >> Sent: Tuesday, November 03, 2026 08:51 >> To: [email protected] <[email protected]> >> Cc: [email protected] <[email protected]>; [email protected] >> <[email protected]>; David Chaava <[email protected]> >> Subject: [DISCUSS] Planner-level GEOGRAPHY type in Apache Calcite >> >> 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> >
