> The guidance for new feature developers would be: > - Review existing SQL syntax for your feature > - If there are extraordinary reasons to now use SQL syntax, enumerate them > in the CEP > - Performance and correctness take precedence. This is succinct and rational.
The one vulnerability we face: if we add a feature with no corollary in SQL, go our own route with syntax, and then SQL evolves to include something in the future that diverges from our implementation. I think the risk of that is low and we could always implement a redundant syntax that matches the new SQL semantics and support both in the rare case that happens. To your question Stefan - I don't think that's an issue w/what Patrick's putting forward here (scope creep). This directive is pretty simply formalizing the following in the context of adding new features to CQL: > If there's prior art in SQL bias towards conformance with that. If not we do > our own thing. On Thu, Nov 6, 2025, at 3:55 AM, Štefan Miklošovič wrote: > This is overall reasonable line of thinking however as with anything I > think it has some "buts": > > Let's say we want to implement a feature / idea / extend CQL in some > manner. Then, based on what you wrote, we will investigate how it is > done in the SQL world. Once we come to the realisation that there is > no such construct similar to ours we want to introduce, we will fall > back from "use of SQL syntax when possible when adding new features" > to our customly crafted CQL. > > There is a parallel thread about bringing SQL to Cassandra. Once > people start to use SQL layer, how are we going to translate the > calling of this feature to SQL if there is no resemblance to that? > > Does this mean that whatever new we will want to introduce, which does > not exist in SQL, will be reserved to CQL only and then SQL will be > just a subset? Is a user supposed to switch between CQL and SQL (how?) > just to be able to start to use CQL syntax there is no counterpart in > SQL? > > My gut feeling says that it will be quite a messy situation where we > will be introducing features on syntax level based on how "SQL-close" > it is and we will be switching between syntaxes based on where that > particular feature is implemented in and how. > > If we agree on SQL first approach and we ban the evolution of CQL then > what might happen is that people will just abandon the idea they have > just because there will not be SQL parity. I think that unnecessarily > restricts innovation. I was always more practical and goal-oriented > when it comes to this stuff. > > I understand that this is for now mostly only theoretical exercise I > am conducting here but I would still like to have answers to this in > general. > > On Wed, Nov 5, 2025 at 8:18 PM Patrick McFadin <[email protected]> wrote: > > > > This is a focused discussion stream to contemplate future CQL syntax as we > > add new features. > > > > Succinctly, I proposed to ratify the use of SQL syntax when possible when > > adding new features. Prior work demonstrating that this can be successful > > is CEP-52. Needed to add labels to schema, took the previously art in > > PostgreSQL and used it. > > > > This is NOT a proposal to backport or retrofit syntax. What is already in > > CQL is a part of the spec. The separate topic of adding full SQL support > > will be in a different DISCUSS thread. > > > > The guidance for new feature developers would be: > > - Review existing SQL syntax for your feature > > - If there are extraordinary reasons to now use SQL syntax, enumerate them > > in the CEP > > - Performance and correctness take precedence. > > > > Patrick >
