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