Think we're just talking past each other / not aligned yet. I see this as 2 conversations we can have independently: 1. Future path of more formal endpoint / API support of various popular APIs (SQL, GraphQL, etc). Your question of "do we go strict subset, franken-extended, ??" 2. Future guidance / alignment on how we evolve and add new things to CQL (this thread) To your question: > > 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? We could either go superset of SQL or subset of SQL w/our more formally aligned SQL support. That doesn't necessarily sway how we approach adding new functionality in the CQL space w/that API going forward does it?
On Thu, Nov 6, 2025, at 8:49 AM, Štefan Miklošovič wrote: > 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 > > > > >
