Dmitrii Aleksandrov

https://github.com/SeaQL/sea-orm/pull/2628 has been merged into `master` and will be released in `2.0.0`

I understand. I'm pointing out that the SQL asterisk is also valid with these tables. I'd like to find a clean way to support it right away

> I honesty think we're running out of "innovation token" to make this change I agree. It feels like we should be wrapping up this SeaQuery release soon and moving...

What about the semicolon check in CI? Looks good otherwise

But now I'm stuck with this failing `ExprTrait::as_enum` doctest. I've read this [explanation of `AsEnum`](https://github.com/SeaQL/sea-query/pull/922/#issuecomment-3183979509) and I understand the need to separate quoted (case-sensitive) and unquoted (case-insensitive) casts, but I...

Your list of non-terminal nodes assumes that they can only be built of other expressions and operators/separators/parentheses that combine them; and that everything can be "lowered" to these primitives. But...

I understood this idea. Yes, this is possible. But the problem in my view is that `Keyword` is not actually a valid `Expr`. IMO, `Expr::Keyword` and `Expr::TypeName` should not exist....

Doesn't change anything. These types still allow you to construct invalid expressions from arbitrary keywords: `let keyword_expr = Expr::Atom(Atom::Keyword(..))`. I don't want to allow expressions like `IF + 3`. I...

For flexibility, we already have `cust*` methods and `Cust`/`Custom` variants. I adore them. When something isn't supported natively, they usually provide a working solution. I'm not sure if we need...

It's really simple. Only the variants *that are actually expressions* should stay in `Expr`. Use `expr + 1` as a quick test. "Real" expressions should be composable. I don't have...