> 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.
This isn’t how I understand the motivations / proposal. As you call out, if a CQL feature doesn’t exist in SQL then we don’t have a reference to go off of so we must define our own way to do things. I don’t think this is a blocker for anything as it’s basically just the current state of things. Where I think this proposal shines best is when there is overlap. "Learn the rules well, so you know how to break them properly”. When we work on a feature similar to something else that exists we are able to use this as a baseline to help flesh out our API. Example that comes to mind is the transaction syntax in CQL; there was a ton of back and forth on what the SELECT semantic would be and on what the “return select” semantic would be (we also knew future questions that would pop up since we saw them in prior art, so we had the answer to these questions before the work started, such as multiple return selects with different schemas)… the fact that there was preexisting art made it easier to make an informed decision on the semantics. One of my pet peeves with Apache Cassandra is that some user facing features do not think through semantics or UX well. You will see this a ton with my fuzz testing, where I find inconsistencies and flat out incorrect behavior all the time…. When we have a baseline we can compare against we should be able to argue why we deviate or went another way, and if we can not it tells me we have not thought about the feature enough in a specific area. > On Nov 9, 2025, at 7:58 PM, Ekaterina Dimitrova <[email protected]> wrote: > >> Future guidance / alignment on how we evolve and add new things to CQL (this >> thread) > > This is how I understood the goal of the current discussion too. While I > still think Stefan brings valid points that we should consider. > > Overall, I agree with where this discussion is heading to and my personal > opinion and questions align with what Joseph said here: > >> I also like deferring to using words and concepts from SQL (and PostgreSQL >> when it's not a standard SQL feature) when we can in CQL going forwards, and >> I think it's just common sense API design if we can adopt a concept or verb >> that already has mental models let's do that. Also agree that there will be >> cases where there are very good reasons to deviate. Maybe we could try to >> enumerate some (non-exhaustive) common reasons we may choose to deviate, >> e.g. if the choice makes Cassandra significantly more secure, performant or >> easy to use? when it's not a standard SQL feature) when we can in CQL going >> forwards, and I think it's just common sense API design if we can adopt a >> concept or verb that already has mental models let's do that. Also agree >> that there will be cases where there are very good reasons to deviate. Maybe >> we could try to enumerate some (non-exhaustive) common reasons we may choose >> to deviate, e.g. if the choice makes Cassandra significantly more secure, >> performant or easy to use? and I think it's just common sense API design if >> we can adopt a concept or verb that already has mental models let's do that. >> Also agree that there will be cases where there are very good reasons to >> deviate. Maybe we could try to enumerate some (non-exhaustive) common >> reasons we may choose to deviate, e.g. if the choice makes Cassandra >> significantly more secure, performant or easy to use? verb that already has >> mental models let's do that. Also agree that there will be cases where there >> are very good reasons to deviate. Maybe we could try to enumerate some >> (non-exhaustive) common reasons we may choose to deviate, e.g. if the choice >> makes Cassandra significantly more secure, performant or easy to use? > Also agree that there will be cases where there are very good reasons to > deviate. Maybe we could try to enumerate some (non-exhaustive) common reasons > we may choose to deviate, e.g. if the choice makes Cassandra significantly > more secure, performant or easy to use? > > На нд, 9.11.2025 г. в 17:49 Patrick McFadin <[email protected] > <mailto:[email protected]>> написа: >> Just a reminder to everyone, we have another thread on this topic. >> >> To answer your question. Sometimes, but it’s not official policy. As someone >> looking at the devs for Cassandra, I’ve been jumping in those threads to try >> and get us going that direction. This is to formalize that position. >> >> On Sat, Nov 8, 2025 at 4:38 PM guo Maxwell <[email protected] >> <mailto:[email protected]>> wrote: >>> I have a question: looking back over the past few years, haven't the new >>> CQL syntax features we've added been designed with reference to PostgreSQL >>> or MySQL? >>> >>> >>> Joseph Lynch <[email protected] >>> <mailto:[email protected]>>于2025年11月8日 周六21:24写道： >>>> I also like deferring to using words and concepts from SQL (and PostgreSQL >>>> when it's not a standard SQL feature) when we can in CQL going forwards, >>>> and I think it's just common sense API design if we can adopt a concept or >>>> verb that already has mental models let's do that. >>>> >>>> Also agree that there will be cases where there are very good reasons to >>>> deviate. Maybe we could try to enumerate some (non-exhaustive) common >>>> reasons we may choose to deviate, e.g. if the choice makes Cassandra >>>> significantly more secure, performant or easy to use? >>>> >>>> -Joey >>>> >>>> On Fri, Nov 7, 2025 at 10:47 AM Jordan West <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> Regarding the original proposal in this thread with its limited scope, I >>>>> am supportive and would +1 such a change >>>>> >>>>> On Thu, Nov 6, 2025 at 16:57 Patrick McFadin <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> I was trying to specifically stay away from a backport discussion. But >>>>>> since you mention it, I think the only way to do that is to make it >>>>>> additive. The base CQL syntax stays the same but in the same grammar >>>>>> there is an alternate syntax that does the same thing. >>>>>> >>>>>> One example I can think of is typecasting. Same feature, different >>>>>> syntax. >>>>>> >>>>>> Patrick >>>>>> >>>>>> > On Nov 6, 2025, at 4:38 PM, Joel Shepherd <[email protected] >>>>>> > <mailto:[email protected]>> wrote: >>>>>> > >>>>>> > On 11/5/2025 11:16 AM, Patrick McFadin 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 not use SQL syntax, >>>>>> >> enumerate them in the CEP >>>>>> >> - Performance and correctness take precedence. >>>>>> > >>>>>> > This seems pretty workable. >>>>>> > >>>>>> > A question it leaves me wondering about is: are there opportunities >>>>>> > with CQL to make existing syntax more SQL-like while preserving >>>>>> > semantics, correctness, etc., and if so should they be pursued? Or is >>>>>> > the fourth piece of guidance to leave existing CQL syntax alone? >>>>>> > >>>>>> > -- Joel. >>>>>> > >>>>>> >
