Hi Max, Sergey, Dylan, Thank you for the thoughtful feedback.
I understand the concern Sergey raised about long-term Flink-specific planner handling, particularly in light of the BITMAP example. I also agree with Dylan that discussing GEOGRAPHY semantics with the Calcite community early would help avoid divergence. Max’s question about how a future transition to a Calcite type would work is important for the FLIP. Would you consider this sequence acceptable: first discuss and document GEOGRAPHY semantics with the Calcite community; then, if the Flink FLIP reaches consensus and the PR passes review, allow the core Flink GEOGRAPHY type to be merged without waiting for a Calcite implementation or release? Calcite implementation and any subsequent Flink migration would be discussed separately. If you would not consider that sequence safe, what specific Calcite milestone would you see as a prerequisite for merging the Flink PR? What compatibility requirements should we address in the FLIP? Thanks, David On Tue, Sep 29, 2026 at 9:25 AM dylanhz <[email protected]> wrote: > +1 for discussing with Calcite first. > > Whether each project adopts the type is a separate decision, but > discussing the semantics early should make any future switch to native > Calcite support easier. > > New types touch many parts of the system, and fixes will be needed over > time. RAW has been in Flink for years and still has a similar problem. I > also found another issue involving UNION and nullability. > > I'd suggest putting together a guide for adding new types: what to check, > which SQL cases to test, and what pitfalls we've already found. We can keep > updating it as more issues come up. This would help with both > Calcite-native and Flink-specific types. > > ---------- > Best regards, > dylanhz > > > > > > 2026年9月29日 04:55，Sergey Nuyanzin <[email protected]> 写道： > > > > The problem of skipping Calcite for now will bite later > > > > Earlier there was mentioned BitMap type > > And now it appears that we need to hack Calcite classes to support edge > cases > > for instance [1]. > > To be honest I'd like to avoid this with other types > > > > [1] https://issues.apache.org/jira/browse/FLINK-40839 > > > > On Mon, Sep 28, 2026 at 3:41 PM Maximilian Michels <[email protected]> > wrote: > >> > >> Thanks for looking into adding GEOGRAPHY support! I think it comes > >> down to how hard it would be to swap the built-in GEOGRAPHY with a > >> future Calcite GEOGRAPHY. If we keep the implementation around > >> GEOMETRY slim and only add basic functions, it may be feasible to skip > >> Calcite for now. Modeling GEOGRAPHY as defined in the Iceberg table > >> spec looks like a pretty safe bet. > >> > >> -Max > >> > >> On Wed, Sep 23, 2026 at 2:41 PM David Chaava via dev > >> <[email protected]> wrote: > >>> > >>> Hi everyone, > >>> > >>> > >>> Just bringing the GEOGRAPHY FLIP back to the list in case it got > buried. > >>> The discussion has been quiet for a while, and we’d still appreciate > the > >>> community’s feedback on the proposal and the open implementation-path > >>> question. > >>> > >>> > >>> If you have a chance, please share your thoughts on the proposal. Any > >>> feedback on what we should address to move the discussion forward > would be > >>> very helpful. > >>> > >>> > >>> Thanks, > >>> David > >>> > >>> On Fri, Jul 17, 2026 at 8:03 PM David Chaava <[email protected]> > >>> wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> We would like to ask for help moving the Geography type support FLIP > >>>> forward. > >>>> > >>>> The discussion has been open for some time, and we have now prepared > the > >>>> first PR for the core GEOGRAPHY logical type support so the proposal > can be > >>>> reviewed against concrete implementation work [1]. > >>>> > >>>> This PR focuses on the base logical type support and wiring, while > keeping > >>>> unrelated dependency and format-specific changes separate to make the > >>>> review easier. > >>>> > >>>> Best regards, > >>>> David > >>>> > >>>> [1] https://github.com/apache/flink/pull/28740 > >>>> > > > > > > > > -- > > Best regards, > > Sergey > >
