GeezerVison

For DuckDB, where FROM-first queries (docs) and TABLE t are queries like any other:

• isParenthesedSelectAhead() / isParenthesedFromItemAhead() accept (FROM, and (TABLE when a table name follows and then ), a set operator, ORDER, LIMIT, OFFSET or FETCH. So (table = 'hits'), (table) and (table.a) stay expressions on a column named table (ClickHouse's system.parts), and Oracle's TABLE(...) is untouched.
• In Select(), FROM-first selects and TableStatement join the alternatives that can be followed by a set operation; SetOperationList accepts them as operands and hoists a trailing ORDER BY/LIMIT/OFFSET from a last TableStatement as it does for a PlainSelect. The separate TableStatement() statement alternative is now covered by Select().
• isFromFirstSelectAhead() also recognises a following set operator, stops at the end of the enclosing parentheses, and follows the token chain instead of calling getToken(i) per token. A bare FROM t, also parenthesized, and pipe queries are still FromQuery.
• TableStatement uses Select.appendTo, and TableStatementDeParser prints the WITH clause, OPTION, FETCH and the isolation level. CREATE TABLE ... AS takes any query, e.g. TABLE a UNION TABLE b; FROM (TABLE s.t) x now parses.
• All these inputs were errors in every dialect. On ~9,760 statements extracted from this repository's tests, parse results, statement types and output are identical to master for everything that parsed there.
• checkGrammarAmbiguity: no conflicts. ./gradlew check: 10,116 tests, 0 failures.
• DuckDB's own test suite (test/sql, 70,729 statements): 155 more parse, none less.