[PR] Support parsing more Oracle CREATE TABLE SQL (RECORDS VARIABLE, CHARACTERSET, partition-level STORE IN) [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu opened a new pull request, #39543:
URL: https://github.com/apache/shardingsphere/pull/39543

   - support RECORDS VARIABLE n, DATA IS BIG/LITTLE ENDIAN and CHARACTERSET access parameters for external tables
   - accept partition-level STORE IN clause in range and list partition descriptions of composite partitioned tables
   - add parser IT cases for the CREATE TABLE and ALTER TABLE statements from issue #27095
   
   Fixes #27095
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Support parsing more Oracle CREATE TABLE SQL (RECORDS VARIABLE, CHARACTERSET, partition-level STORE IN) [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu merged PR #39543:
URL: https://github.com/apache/shardingsphere/pull/39543


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Support parsing more Oracle CREATE TABLE SQL (RECORDS VARIABLE, CHARACTERSET, partition-level STORE IN) [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu commented on PR #39543:
URL: https://github.com/apache/shardingsphere/pull/39543#issuecomment-5377822994

   ### Result
   
   **Review Result: Mergeable**
   
   All 7 files of PR #39543 were reviewed. The two parsing gaps (external-table access parameters `RECORDS VARIABLE n` / `DATA IS BIG/LITTLE ENDIAN` / `CHARACTERSET`, and partition-level `STORE IN` for composite partitioned tables) are addressed by grammar-only widening changes with 6 correctly asserted IT cases; the local `InternalOracleParserIT` run passed 1853 tests with zero failures, and no candidate finding met the blocking conditions.
   
   ### Evidence
   
   - **Review scope**: head `6b614773796`, base and merge-base both `be2904011a2`; the local triple-dot file list exactly matches GitHub `/pulls/39543/files` (7 files, +118/-5); the PR has no comments and no review threads.
   - **Behavior cluster C1 (external-table access parameters)**: `DDLStatement.g4:1121` adds the `VARIABLE INTEGER_` branch to `recordsSpec`; `DDLStatement.g4:1124` and `DDLStatement.g4:1128` add `dataEndianSpec` and `characterSetSpec` into `recordFormatOption`; all 5 new tokens (from `OracleKeyword.g4:3783`) are covered by the `unreservedWord` fallback at `BaseRule.g4:85`, so identifier usage is unaffected. Syntax basis: the issue's SQL comes from official Oracle documentation examples (the Utilities guide defines `RECORDS VARIABLE`, `DATA IS BIG/LITTLE ENDIAN`, and `CHARACTERSET` for ORACLE_LOADER access parameters; the 19c SQL Reference covers `access_parameters → opaque_format_spec` under CREATE TABLE).
   - **Behavior cluster C2 (partition-level STORE IN)**: `rangePartitionDesc` (`DDLStatement.g4:1397`) and `listPartitionDesc` (`DDLStatement.g4:1410`) each gain a trailing `STORE IN (tablespace, ...)` alternative, following the composite partitioning example in Oracle's VLDB and Partitioning guide (`PARTITION p2 VALUES LESS THAN (2000) STORE IN (...)`). The three alternatives have distinct leading tokens (`LP_` / `SUBPARTITIONS` / `STORE`), so there is no ordering ambiguity.
   - **Behavior cluster C3 (test validity)**: the 6 new cases (5 create-table + 1 alter-table) assert only tables and column definitions in the expected XML, matching existing convention; `alter_table_add_virtual_column` asserts only the table name, consistent with `visitAddColumnSpecification` producing no segment for `virtualColumnDefinition` today, and the case still fails the IT with a parse exception on any grammar regression, so it is valid protection.
   - **Regression and blast radius**: every change widens the accepted set and narrows no existing parse path; visitors, statement model, public APIs, and SPIs are untouched; Oracle is a trunk dialect with no branch dialects, and the 5 tokens live only in the Oracle lexer file. `InternalOracleParserIT` (1853 tests, 0 failures, 0 errors, exit 0), `spotless:apply` (exit 0), and `checkstyle:check -Pcheck` (exit 0) are sanitized local verification results. Peer merged PRs (#39524, #39542) did not update RELEASE-NOTES, and this PR stays consistent.
   - **Candidate disposition**: "bare partition-level `STORE IN` accepted even without hash subpartitioning" and "access-parameter options accepted in any order and repetition" are both wider than the official railroads but follow the grammar's existing permissive style; neither is required for correctness or safety, so both are classified as non-blocking observations and not published.
   
   ### Coverage
   
   - Reviewed head: `6b614773796` (base `be2904011a2`, single commit, no previous head).
   - Authoritative requirements: all 6 SQL groups from issue #27095 parse and have case coverage; 7/7 files mapped to 3 behavior clusters; no churn-only files.
   - Discovery: the root-cause, blast-radius, and tests-runtime lenses plus the convergence pass are complete with 0 new independent candidates; no candidate passed the Finding Proof Gate.
   - Dialect and documentation: target dialect Oracle (trunk, no branch dialects to check); official evidence from the Oracle 19c SQL Reference, the Utilities guide, and the VLDB and Partitioning guide; repository side checked parser IT resources and RELEASE-NOTES convention, with no baselines or docs requiring regeneration.
   - Unresolved gaps: none. This conclusion is a code-scope review; GitHub Actions/CI was not queried and was not reviewed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org