[minleejae]

Oracle DML statements such as INSERT INTO employees (id) VALUES (1) RETURNING id INTO :out_id currently fail to parse. RETURNING id BULK COLLECT INTO ids also fails because BULK is consumed as a select-item alias.

Support named output binds, JDBC output parameters, and BULK COLLECT INTO through the shared RETURNING clause used by INSERT, UPDATE, DELETE and MERGE. Expose the collection mode through ReturningClause.isBulkCollect() and setBulkCollect(boolean), and preserve it when rendering SQL. Existing plain variable and user-variable targets retain their representation.

BULK and COLLECT remain ordinary identifiers and aliases. Only the complete BULK COLLECT INTO sequence introduces the collection clause.

Validation covers all four DML statements, default and Oracle configurations, AST target types, SQL deparsing and reparsing, JDBC output parameter numbering after input binds, incomplete clauses, existing target forms, and identifier/alias compatibility.

Oracle references: RETURNING INTO, JDBC DML Returning.

Checks: Maven verify on JDK 21 (11,893 tests, 25 skipped) and Gradle check on JDK 17 (11,911 tests, 25 skipped), with zero failures or errors. Gradle also passed grammar ambiguity, formatting, Checkstyle, PMD and SpotBugs checks. Local formatting checks used upstream/master as the comparison ref because origin/master belongs to the fork.

A short JMH run of JSQLParserBenchmark.parseSQLStatements used JDK 17, the latest parser, 3 forks, 3 x 1-second warmups and 5 x 1-second measurements per fork. Baseline: 18.000 +/- 1.005 ms/op; this change: 18.019 +/- 1.042 ms/op. The intervals overlap; this run does not show a measurable slowdown.

AI assistance: prepared with Codex.

[manticore-projects]

Very nice, thank you!