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