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. >>>> > >>>> > >>>> >>>
