The EdgeQL query has no obvious meaning, unless (,) calculates the cross product. Saying

SELECT Table1, 1

returns each row of Table1 along with 1 and that 1 returns the set {1} means that you have arbitrarily assigned each row of Table1 a row from the set {1}. This gives what you want in the case of a scalar, but what about a non-scalar.

For example, suppose Table1 contains (John, Smith), (Alice, Perkins), (Bob, Best). Then, what should

SELECT Table1, {1,2}

return? If you do not say cross product, you have arbitrarily assigned rows to one another, resulting in meaningless data. If you say cross product, then you have rewritten the sql expression

SELECT * FROM Table1, (VALUES (1), (2))

I don't disagree the SQL syntax is longer and has some unnecessary keywords, but unlike EdgeQL, the query means something particular.

In EdgeQL, expressions are element-wise functions over the cross-product of the input sets:

    edgedb> SELECT {'First', 'Second'} ++ '!';
    {'First!', 'Second!'}

EdgeQL queries are essentially set comprehensions.

Right, so SELECT Table1 and SELECT 1 compose to SELECT Table1, 1 in the same way that

SELECT 1

and SELECT * FROM TABLE1 and SELECT 1 compose to

> SELECT * FROM TABLE1, (SELECT 1)

Aside from the different syntax, it is the same kind of composition. Not sure what EdgeQL has gained here, then.

Erm, isn’t the syntax the whole point of this discussion?

Is this such a common problem that you need a new language to solve it?

We think that people struggling with writing good/advanced SQL queries and the existence of ORMs and other heavy frameworks to make RDBMSes "friendly" is a serious problem. And inventing a a new querying language is a necessary step to make relational databases more accessible.

Just to clarify (and I strongly dislike overuse of ORMs)...

Some people use a thing x

A subset of those people use a subset of x called y

This subset of people have built a tool to make y easier to express

Thus x is invalid

I think that's a really bad argument, if everyone was using ORMs then we'd all merrily forget about SQL and just use ORMs which would become the new "language for structuring queries", but we don't all, and EdgeDB in particular thinks that ORMs provide a much degraded expression set from SQL and thus want to tweak X so that it's as expressible as the tool to express Y but without making it just about Y... I think your goal boils down to shifting the trade-off point between X and Y - the extreme of which is writing a very expressive Y that also supports X but in a non-expressive manner.