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
