On 11/6/2025 4:55 PM, Patrick McFadin 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.
Yeah, that's along the lines of what I was thinking. The existing CQL
syntax remains but more idiomatic SQL syntax is available if that's what
a given user prefers.
Thanks -- Joel.
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.
