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