Keywords used only query expressions should not be reserved everywhere

[jclark]

At the moment, keywords used only in query expressions are reserved everywhere.

This would create a problem for adding #1134 in Swan Lake, since reserving new keywords would create an incompatibility.

If we do a new keyword for #1137 (e.g. aggregate or collect), then we need to handle that here also.

[jclark]

This covers:

• where
• join, outer, equals, on
• order by, ascending, descending
• limit
• on conflict
• group by
• TBD keyword for aggregation e.g. collect

[jclark]

I think group by should be reasonably straightforward to solve:

• we can treat it as a single keyword that is spelled with whitespace, rather than as two separate keywords
• I don't think it's possible to have two adjacent identifiers in an expression where neither identifier is a keyword: there's always some operator symbol between them.

[jclark]

Each from is paired with a select, collect or do, with the query pipeline in between, so one can keep track of the number of "open" froms, and recognize some keywords only when there is an open from i.e. collect, select and keywords occurring only in the query pipeline.

This still creates potential (albeit fairly unlikely) incompatibilities in that use of collect within the query pipeline would become syntactically invalid.

[jclark]

I think a better solution to this is just to say that the identifiers that start a clause (other than from and let, which is already reserved) should not be reserved at all.

Only tricky case I think is the order direction (ascending or descending) in an order by clause.

[jclark]

@KavinduZoysa @hasithaa Did you make ascending, descending not reserved?

It would be nice to do that also, but I'm 100% sure if that can be done without problems.

[KavinduZoysa]

@jclark, ascending and descending keywords are still reserved. But group and collect are not reserved. We will revisit other keywords under this lang issue and fix them.

[jclark]

I think just "conflict" should be NR rather than "on" "conflict".

[jclark]

This issue has dealt with keywords that start clauses. Other keywords are dealt with by #1255.