Parse ALTER FUNCTION, PROCEDURE and TRIGGER actions and MySQL routine definers

[minleejae]

Builds on #2811, which adds ConfigurationParameterChange; please review that PR first. This PR is the second commit on top of it.

Purpose

Parse the routine and trigger changes that PostgreSQL and MySQL dumps and migrations emit:

• PostgreSQL ALTER FUNCTION, ALTER PROCEDURE and ALTER ROUTINE, and ALTER TRIGGER, are UnsupportedStatements. pg_dump writes ALTER FUNCTION f(int) OWNER TO role for every function.
• MySQL ALTER FUNCTION/ALTER PROCEDURE characteristics, such as ALTER PROCEDURE p COMMENT 'x' SQL SECURITY INVOKER, are UnsupportedStatements.
• MySQL CREATE DEFINER = ... FUNCTION|PROCEDURE and CREATE TRIGGER IF NOT EXISTS fail.
• A MySQL trigger with a procedural body, such as FOR EACH ROW BEGIN IF ... END IF; END, fails. A body of plain statements parses, but it takes the ; after END, so a script fails at the next statement.

Current design (As-is)

• Alter() has no alternative for these statements, so its fallback captures them as UnsupportedStatements.
• Create() sends every DEFINER prefix to CreateTrigger(), so CREATE DEFINER = ... FUNCTION fails. CreateFunctionalStatement has no definer.
• The MySQL CreateTrigger() reads its body with SingleStatement() | Block(). Block() accepts SQL statements only and consumes a following semicolon. The MySQL trigger path also drops OR REPLACE.

Target design (To-be)

• Add AlterRoutine for PostgreSQL ALTER FUNCTION|PROCEDURE|ROUTINE and MySQL ALTER FUNCTION|PROCEDURE. Both dialects share one statement because they change the same routine characteristics; only the spelling differs.
  • getRoutineType() and getRoutine(), the existing RoutineReference with the optional PostgreSQL argument types.
  • Action: CHARACTERISTICS (the default), RENAME, OWNER, SET_SCHEMA and DEPENDS_ON_EXTENSION with isNoDependency(). Payloads of other actions are kept, as in AlterDatabase.
  • getCharacteristics(): a mutable list of the new RoutineCharacteristic in source order, plus PostgreSQL's isRestrict().
• RoutineCharacteristic.Kind has one value per characteristic, and each renders its own keywords:
  • PostgreSQL: IMMUTABLE, STABLE, VOLATILE, CALLED_ON_NULL_INPUT, RETURNS_NULL_ON_NULL_INPUT, STRICT, [NOT_]LEAKPROOF, PARALLEL_*, COST, ROWS, SUPPORT and CONFIGURATION_PARAMETER;
  • MySQL: COMMENT, LANGUAGE_SQL, CONTAINS_SQL, NO_SQL, READS_SQL_DATA and MODIFIES_SQL_DATA;
  • shared: SECURITY_DEFINER and SECURITY_INVOKER. getSecurityClause() keeps the SECURITY, EXTERNAL SECURITY or MySQL SQL SECURITY spelling.
  • COST, ROWS, SUPPORT and COMMENT keep their value as SQL text in getValue(). getComment() returns the COMMENT literal as a StringValue, read with the parser's dialect escaping, so getNotExcapedValue() is the text MySQL stores. SET/RESET reuse ConfigurationParameterChange and its grammar production from Parse PostgreSQL ALTER DATABASE and share typed database options #2811.
• Add AlterTrigger for PostgreSQL ALTER TRIGGER name ON table RENAME TO | [NO] DEPENDS ON EXTENSION, with the table as a Table.
• Grammar:
  • A semantic lookahead selects AlterRoutine only when a known alteration follows the routine name and signature. Other forms, such as Oracle's COMPILE, DB2's NOT FENCED or SQL Server definitions without the SQL Server dialect, remain UnsupportedStatements; with Dialect.SQLSERVER they are still CreateFunctionalStatements.
  • A statement's characteristics belong to one dialect. PostgreSQL characteristics are space-separated and may end with RESTRICT; MySQL characteristics take no argument list and no ALTER ROUTINE. Invalid combinations, such as commas or RENAME TO g RESTRICT, are errors.
  • ALTER TRIGGER is selected only when the whole statement matches.
  • No new reserved words; characteristic words are matched as identifiers.
• MySQL CREATE:
  • CreateFunctionalStatement.getDefiner() holds the DEFINER account as the MySqlDefiner that views and triggers use. Create() now picks the trigger or routine after the definer.
  • CreateTrigger.isIfNotExists() records IF NOT EXISTS. MariaDB's OR REPLACE is kept on the MySQL path; combining it with IF NOT EXISTS is an error.
  • A BEGIN ... END trigger body with only SQL statements remains a Block. Other compound bodies (IF, CASE, loops, DECLARE, labels) are captured with the existing RoutineBodyBoundary, as for CREATE PROCEDURE, and kept as an UnsupportedStatement body. Both leave the ; after END to separate statements. Block() now uses a shared BeginEndBlock() production; its behavior is unchanged.
• Wiring:
  • StatementVisitor defaults, StatementVisitorAdapter, StatementDeParser (SET values through the expression deparser) and TablesNamesFinder (the ALTER TRIGGER table);
  • validation: the existing alterFunction and alterProcedure features and new alterRoutine and alterTrigger. PostgreSQL enables all four, MySQL and MariaDB the first two;
  • statement feature analysis reports MODIFIES_SCHEMA;
  • usage guide, README and index.

Validation

• New and extended tests (26 methods, 125 cases) cover:
  • parse, toString, deparse and reparse with Dialect.POSTGRESQL, Dialect.MYSQL, Dialect.MARIADB and without a dialect, plus statement boundaries in scripts;
  • the AST of every action, characteristic kind, security spelling and signature;
  • MySQL COMMENT literals ('it\'s', 'it''s', "dq", backslash escapes, Korean text and emoji) against the text MySQL stores;
  • unmodelled forms that remain UnsupportedStatement, rejected combinations, and unchanged SQL Server routines;
  • definer accounts, trigger IF NOT EXISTS/OR REPLACE, structured and procedural trigger bodies, and unterminated bodies;
  • visitor dispatch, table discovery, validation capabilities and statement features.
• Java 17 offline Gradle spotlessApply check: 10,550 tests, 10,525 passed, 25 skipped, zero failures/errors. The grammar choice conflict check passes.
• Compared with master (bdf8ac31) on a corpus of 635 MySQL 8.4 and PostgreSQL 18 DDL/DCL statements, each accepted by the server, plus variants (the ALTER DATABASE/CHARSET fixes come from Parse PostgreSQL ALTER DATABASE and share typed database options #2811):
  • Fixed with Dialect.POSTGRESQL and without a dialect: ALTER FUNCTION f2(int) OWNER TO/RENAME TO/SET search_path = ..., ALTER PROCEDURE p1(int) SECURITY DEFINER, ALTER ROUTINE f2(int) IMMUTABLE and ALTER TRIGGER trg ON users RENAME TO trg_new.
  • Fixed with Dialect.MYSQL and without a dialect: ALTER PROCEDURE ... COMMENT ... SQL SECURITY INVOKER, ALTER FUNCTION ... READS SQL DATA, CREATE DEFINER = ... FUNCTION|PROCEDURE, CREATE [DEFINER = ...] TRIGGER IF NOT EXISTS and the trigger with an IF body.
  • The script with a trigger compound body now splits into its two statements.
  • No regressions. Compared with Parse PostgreSQL ALTER DATABASE and share typed database options #2811, only these cases change in the AST or rendered SQL.
• 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).

Integration validation

Applied #2806–#2819 together on master (bdf8ac31), with the stacked PRs on top of their bases (#2806 → #2807 → #2808, #2806 → #2809 → #2810 and #2811 → #2812).

• Each branch merges cleanly into master. Between the branches, conflicts are limited to adjacent additions (README/index rows, usage sections, imports, visitor and feature lists, one enum line and one alias guard).
• The integrated build passes Java 17 offline Gradle spotlessApply check: 11,494 tests, 11,469 passed, 25 skipped, zero failures/errors. The grammar choice conflict check passes.
• On a corpus of 635 MySQL 8.4 and PostgreSQL 18 DDL/DCL statements, each accepted by the server, the integrated build parses 265 of 271 MySQL statements (master: 206) and 363 of 364 PostgreSQL statements (master: 328). Every MySQL 8.4 non-reserved word and PostgreSQL 18 unreserved or column-name keyword parses as a column and table name.
• On paired MySQL 8.4 and PostgreSQL 18.3 servers, all 263 MySQL and 362 PostgreSQL statements rendered by the integrated build give the same results as the originals.