In my case, I am primarily trying to decide whether or not I can push an operation down or how to push the operation down.
For an actual engine, knowing it at plan time will matter for index selection, etc. Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Julian Hyde <[email protected]> Sent: Tuesday, 03 November 2026 13:05:16 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Planner-level GEOGRAPHY type in Apache Calcite 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> >
