GeezerVison

#2811 and #2812 are merged, and this PR is rebased on master. It reuses the MySQL routine characteristics of #2812.

Purpose

Expose the characteristics of MySQL CREATE FUNCTION and CREATE PROCEDURE, such as COMMENT 'proc comment', DETERMINISTIC, READS SQL DATA or SQL SECURITY INVOKER. Today they are only loose tokens in functionDeclarationParts:

• A tool that moves a MySQL routine comment elsewhere, for example into PostgreSQL's COMMENT ON FUNCTION, has to find the token and decode the MySQL escapes itself.
• Checking whether a function is DETERMINISTIC means matching keywords among the routine's tokens.
• Parse ALTER FUNCTION, PROCEDURE and TRIGGER actions and MySQL routine definers #2812 already models the same characteristics for ALTER FUNCTION/ALTER PROCEDURE.

Current design (As-is)

• CreateFunctionStatement() captures everything after FUNCTION/PROCEDURE with captureFunctionBody(), a token loop that RoutineBodyBoundary stops at the end of the routine. The tokens become functionDeclarationParts and render the statement.
• The capture does not distinguish the header, the characteristics and the body. A COMMENT literal is kept only as written, for example 'it\'s'.
• RoutineBodyBoundary treats the SET of a CHARACTER SET return type as the start of the body.

Target design (To-be)

• With Dialect.MYSQL or Dialect.MARIADB, the capture parses the characteristics between the routine header (name, parameters and RETURNS type) and the body with Parse ALTER FUNCTION, PROCEDURE and TRIGGER actions and MySQL routine definers #2812's MySqlRoutineCharacteristic production. The production now takes [NOT] DETERMINISTIC, which MySQL allows only in CREATE, so ALTER FUNCTION f DETERMINISTIC remains unsupported.
  • New RoutineCharacteristic.Kind values: DETERMINISTIC and NOT_DETERMINISTIC.
  • COMMENT is a StringValue read with the dialect's escaping (Parse ALTER FUNCTION, PROCEDURE and TRIGGER actions and MySQL routine definers #2812), so getNotExcapedValue() is the text MySQL stores.
• CreateFunctionalStatement.getCharacteristics() returns them in source order. It is empty without a MySQL dialect, so PostgreSQL's LANGUAGE sql and other dialects' options are not read as MySQL characteristics.
• functionDeclarationParts is still fully populated, including the characteristic tokens:
  • The tokens keep rendering the statement, so the SQL output is byte-identical, including keyword case, and existing token consumers and builders keep working.
  • The characteristics describe those tokens, so the list is read-only rather than a second editable representation. setFunctionDeclarationParts(parts) clears it; the new setFunctionDeclarationParts(parts, characteristics) sets both; appending tokens keeps it.
• RoutineBodyBoundary.isBeforeBody() tells the capture where characteristics can appear. CHARACTER SET and CHAR SET in a return type no longer start the body. The routine still ends at the same token.
• Document the API in the usage guide.

Validation

• New tests (6 methods, 25 cases) cover:
  • the MySQL routine cases of the survey corpora, including CREATE PROCEDURE cp1() COMMENT 'proc comment' SELECT 1, CREATE FUNCTION cf1() RETURNS INT DETERMINISTIC COMMENT 'fn' RETURN 1, COMMENT 'c' LANGUAGE SQL SQL SECURITY INVOKER, and CHARSET, CHARACTER SET, COLLATE and SET(...) return types;
  • with Dialect.MYSQL and Dialect.MARIADB: the characteristic kinds, the same functionDeclarationParts and SQL as without a dialect, deparse, reparse and statement boundaries;
  • COMMENT literals ('it\'s', 'it''s', "dq", 'a\\b', Korean text and emoji) against the text MySQL stores;
  • lower-case keywords kept in the output, and characteristic words inside bodies that stay tokens;
  • the read-only list and the setter and append contract;
  • no characteristics with PostgreSQL or without a dialect; ALTER ... DETERMINISTIC still unsupported.
• Java 17 offline Gradle spotlessApply check: 10,575 tests, 10,550 passed, 25 skipped, zero failures/errors. The grammar choice conflict check passes.
• Compared with master (bdf8ac31) on the survey corpora of MySQL 8.4 and PostgreSQL 18 DDL/DCL: no regressions, and the parse results are those of Parse ALTER FUNCTION, PROCEDURE and TRIGGER actions and MySQL routine definers #2812.
  • Compared with Parse ALTER FUNCTION, PROCEDURE and TRIGGER actions and MySQL routine definers #2812, the rendered SQL of every corpus statement is identical.
  • Only the MySQL routines with characteristics gain them in the AST: DETERMINISTIC and NO SQL in the routine corpus, and the COMMENT, DETERMINISTIC, LANGUAGE SQL and SQL SECURITY comment-corpus cases.
• MySQL 8.4 and PostgreSQL 18.3: every corpus statement this branch parses ran as written on one server and as rendered by toString() on a second, identical server, in the same order. All 211 MySQL and 338 PostgreSQL statements give the same result (success, or the same error).
• The same check on the comment corpora (statements that create, alter and read MySQL and PostgreSQL comments): all 50 MySQL and 65 PostgreSQL statements this branch parses give the same results, including CREATE PROCEDURE … COMMENT … and CREATE FUNCTION … DETERMINISTIC COMMENT …. Afterwards, every stored comment (MySQL table, column, index, partition, routine and event comments; PostgreSQL pg_description) is byte-identical on both servers.
• After rebasing on master (6c5fc6cb): Java 17 Gradle spotlessApply check: 11,480 tests, 11,455 passed, 25 skipped, zero failures/errors. Compared with that master on the same DDL/DCL corpora (with and without a dialect) and comment corpora, parse results, statement classes and rendered SQL are unchanged; there are no regressions.

Integration validation

Applied this PR together with the other comment PRs (#2820, #2821, #2822, #2824), the DDL/DCL PRs #2806–#2819 and #2778 on master (bdf8ac31), with the stacked PRs on top of their bases (#2814 → #2821, #2816 → #2822, #2806 → #2824 and #2811 → #2812 → #2823).

• Each branch merges cleanly into master. Between the branches, conflicts are limited to adjacent additions (README/index rows, usage sections, imports, test methods, visitor and feature lists, an enum line and an alias guard).
• The integrated build passes Java 17 offline Gradle spotlessApply check: 11,877 tests, 11,852 passed, 25 skipped, zero failures/errors. The grammar choice conflict check passes.
• On the corpus of 635 MySQL 8.4 and PostgreSQL 18 DDL/DCL statements, the integrated build parses 265 of 271 MySQL statements (master: 206) and 363 of 364 PostgreSQL statements (master: 328), the same as Share MySQL account names across CREATE USER and DEFINER #2806–Render single spaces in ALTER visibility, FORCE and row level security actions #2819 together. There are no regressions.
• On the comment corpora and an extra set of comment edge cases, the integrated build returns a typed statement for all 80 MySQL statements (master: 67) and for 118 of 119 PostgreSQL statements (master: 76). The exception is a CREATE AGGREGATE setup statement. Every table, column, index, partition, routine, event, user and COMMENT ON comment literal is a StringValue, except COMMENT = _utf8mb4'x', which MySQL rejects.
• On paired MySQL 8.4 and PostgreSQL 18.3 servers, all 263 MySQL and 362 PostgreSQL DDL/DCL statements and all 56 MySQL and 90 PostgreSQL comment statements rendered by the integrated build give the same results as the originals. The stored comments are identical on both servers.