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