feat(trino): support inline SQL UDFs (WITH FUNCTION ... SELECT) [CLAUDE]

[rusackas]

Howdy! I was fixing an Issue on Superset, and it was suggested I file the fix "upstream" so here we go!

Trino supports declaring SQL UDFs inline, in a WITH clause that precedes the query (https://trino.io/docs/current/udf/sql.html):

WITH FUNCTION meaning_of_life()
  RETURNS tinyint
  BEGIN
    DECLARE a tinyint DEFAULT CAST(6 AS tinyint);
    DECLARE b tinyint DEFAULT CAST(7 AS tinyint);
    RETURN a * b;
  END
SELECT meaning_of_life()

These fail to parse (Expecting (), and the semicolons inside BEGIN ... END bodies additionally split the statement in sqlglot.parse. #5178 was closed as low priority with an invitation for a well-tested PR, so here's an attempt. The same gap bit us over in Apache Superset (apache/superset#26162), and I'd rather fix it here than carry a custom dialect downstream.

Parsing follows the functionSpecification / controlStatement grammar from Trino's SqlBase.g4. TrinoParser._parse_cte recognizes FUNCTION <name> entries and parses them into a new exp.FunctionSpecification node (a CTE literally named function still parses as a CTE). Routine bodies support the full control statement grammar (RETURN, BEGIN, DECLARE, SET, CASE, IF/ELSEIF, LOOP, WHILE, REPEAT/UNTIL, ITERATE, LEAVE, loop labels), reusing Declare/Set/Return/Block where they fit and adding statement-level expressions for the rest. Since routine statements are semicolon-separated, the body parser continues across the chunks produced in Parser._parse, the same way _parse_block already does for procedures, so multi-statement scripts still split correctly around the UDF query.

Routine characteristics reuse the existing property machinery, with Trino generator fixes so they round-trip: DETERMINISTIC instead of IMMUTABLE, SECURITY INVOKER instead of SQL SECURITY INVOKER, and DECLARE ... DEFAULT instead of =. Per the grammar, inline functions can't be comma-mixed with named queries, so TrinoGenerator.with_sql emits WITH <functions> WITH <ctes> when both are present. walk_in_scope treats FunctionSpecification as opaque so qualify doesn't try to resolve UDF parameters as outer-scope columns.

Not covered: AS $$...$$ bodies for LANGUAGE PYTHON UDFs (would need $$ tokenizer support in Trino), and CREATE FUNCTION with a BEGIN body, which still splits on inner semicolons today. Happy to follow up on either if there's interest.

Disclosure: implemented with Claude Code, but reviewed, tested (make unit, make unitc, make style) and understood by me. [Edit: it's true, I really look at stuff]

[rusackas]

CC @betodealmeida :D Thanks for suggesting I do this