> > 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]> написа: > 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]> 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]>于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]> 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]> >>>> 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]> >>>>> 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. >>>>> > >>>>> > >>>>> >>>>
