GeezerVison

What

Allow a Hive/Spark LATERAL VIEW to declare an arbitrary number of column aliases, not just two.

Why

LATERAL VIEW ... x AS c1, c2, c3, ..., cN is valid Hive/Spark SQL — json_tuple and similar UDTFs commonly yield many output columns. The grammar only absorbed the first two aliases (#2088); from the third onward the aliases were silently parsed as comma-separated tables in the FROM clause (implicit cross joins):

• PlainSelect.joins incorrectly contained Join(Table("c3")) ... Join(Table("cN"))
• LateralView.columnAlias.aliasColumns stopped at 2

Because toString() re-emits the leaked aliases as the join list, the broken AST round-trips to textually identical SQL, so the bug is invisible to round-trip checks.

Reported in #2433.

How

The column-alias production (LateralView) handled the second alias with an optional [ "," name ] block. This adds a ("," name)* loop immediately after it, so the 3rd…Nth aliases are consumed by the lateral view instead of leaking to the FROM clause. The existing single- and two-alias behaviour is unchanged (the loop simply runs zero times).

Testing

• New HiveTest#testLateralViewManyColumnAliasesIssue2433 parses LATERAL VIEW json_tuple(...) x AS c1, c2, c3, c4, c5, c6, c7 and asserts at the AST level (a round-trip assertion would be vacuous here): PlainSelect.joins is null and LateralView.columnAlias.aliasColumns has size 7.
• Verified the test fails on master (expected: <null> but was: <[c3, c4, c5, c6, c7]>) and passes with this change.
• mvn clean test: 4648 tests, 0 failures, 0 errors (26 skipped) — the existing two-alias case ([BUG] JSQLParser Version 5.1-SNAPSHOT: Lateral View with two aliases recognizes second alias as table #2088) and all other tests unchanged.
• mvn spotless:check: clean.

Fixes #2433