Honestly I do not know where to ask these questions. You are probably right about the out of scope of what I wrote vs. what is proposed but I think that it is not living in a vacuum and it has direct consequences on other things I described.
Yes, technically good proposal, but there are these pesky details we need to somehow cover too. If the "Bringing SQL to Cassandra" thred is better suitable for that discussion, alright. But this is also called "future of CQL syntax" and I think it is somehow related to all SQL / CQL conversation for whoever is trying to introduce new stuff into CQL. On Thu, Nov 6, 2025 at 2:09 PM Josh McKenzie <[email protected]> wrote: > > 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 > >
