Following the very interesting take of Julian in [1], I'd like to start a brainstorming discussion on the opportunity of turning Calcite into a specification-first project, with the aim of providing multiple implementations, and what that would look like.
I am supportive of the initiative, as I am seeing the same trends and discussions Julian mentions, projects like Substrait allow using Calcite as-a-service, but lowering the barrier for new database projects in other languages would surely help adoption and the project to stay relevant in the future. I have witnessed successful rewrites via LLMs as snapshots at time T, but I don't have any experience in maintaining multiple versions over time, which is probably the biggest challenge. The first step Julian suggests is to turn spec and tests into a language agnostic format (like Quidem), so that we have both a "description" of what we want, and a way to verify derived implementations, and I can't agree more. New features and bugs in the specification would be handled as changes to the specification and tests, which are shared, but how would we ensure "consistency" for implementation-specific concepts? Since those concepts are per-implementation, the risk of drift from the "snapshot rewrite at T" might become an issue. I am not talking about lower-level consistency, as that is impossible to achieve across radically different languages, I am talking about conceptual consistency and the capability to match higher-level concepts and interfaces (e.g., the metadata provider), across different implementations. I wonder if a protobuf specification of the internal representation of Calcite would be a good tool to keep the different implementations from drifting. If we move to multiple implementations, we also need to ensure that the burden on maintainers doesn't double, as this is already a problem we face. A "spec-first" approach should ideally automate the validation of all implementations whenever a shared test changes. There are many examples of projects with multiple implementations/bindings (Substrait, Apache Arrow, to name a few projects which are spec-heavy), so maybe looking at what those communities do could be useful. Looking forward to hearing your thoughts and ideas! Best regards, Alessandro
