[CALCITE-6254] Support table function calls in FROM clause without TABLE() wrapper

[barrkel]

CALCITE-6254 Support table function calls in FROM clause without TABLE wrapping.

Currently, when selecting from a table function, the function call needs to be wrapped in TABLE() like this:

    SELECT * FROM TABLE(table_func('args'));

This PR enables this syntax:

    SELECT * FROM table_func('args');

Three tokens of lookahead are necessary to avoid a conflict in the grammar with the dynamic columns feature used by Phoenix

    SELECT * FROM EventLog(lastGCTime TIME)

Three tokens of lookahead means looking past the ( and identifier to the presence of a type production. The table extension clause for dynamic columns requires at least one field, so the empty case of () is not ambiguous either.

[JiajunBernoulli]

1. CI should be successful.
2. Commit message should start with [CALCITE-6254]
3. Maybe we need validate foo table and foo function(Discussion in JIRA).

[barrkel]

1. CI should be successful.

Ack.

2. Commit message should start with `[CALCITE-6254]`

Done. I think the CI failure was because of a . at the end of the commit message.

3. Maybe we need validate foo table and foo function(Discussion in JIRA).

I don't think that makes sense. The identifier scopes for tables and functions are still disjoint, so the existing validation logic in SqlValidatorImpl still applies. The updated grammar produces the same SQL AST as TABLE(foo()). This is why there are no changes outside the grammar and its test.

If the goal is upgraded to being able to handle ambiguous identifiers - e.g. supporting nullary table functions - then things get much harder, both for design and implementation. As I mentioned on the JIRA ticket I think that's a dubious cost/benefit tradeoff.

[sonarcloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[macroguo-ghy]

lgtm