On 2025/11/04 19:42:31 Patrick McFadin wrote:
> Just to be clear, in my initial proposal I said that CQL can never go away.
> It’s a life sentence. Knowing the upgrade cycle that many users are on, it
> will be 50 years before we could even try.
>
> I feel we are at a fork here in the discussion.
>
> Fork 1: Discuss and somehow ratify that we adhere to SQL syntax for new CQL
> features
>
> Fork 2: Formation of a SIG or new DISCUSS thread on how to add SQL as a
> formal path. There have already been throwing around really good ideas and
> should continue. Josh wrapped it up nicely with a “Stateless layer that could
> serve many purposes”
Joel said this a while back:
Conversion doesn't seem practical or desirable: it'd probably result in CQL
and a muddled version of SQL which wouldn't be beneficial for anyone.
I agree with that, and I'd vote accordingly if someone wanted to ratify your
fork 1.
Your fork 2 may or may not need to exist. You don't strictly NEED a SIG,
because you don't need changes in the database to implement it. It could be a
subproject. It could also be an external project. It could also be that
nobody's willing to actually do it for real, in which case it's all talk and
there's no decision to make. I think if someone wants to write a CEP that
exposes lower layer primitives to someone building layers, write the CEP and
negotiate it, great. If someone wants to write an official project-inclusive
CEP for a real SQL layer, write it and negotiate it. If someone wants to do
JOINs for CQL, fine, go for it (is that CEP already around? Ir might be).
Right now all we have is a proposal to constrain CQL to be SQL compatible, and
at least a handful of people have argued about why that's probably a bad idea.
