PostgreSQL CREATE TRIGGER parses execution arguments as data types

Comienza en el análisis de triggers de PostgreSqlDialect y sigue las rutas EXECUTE FUNCTION y EXECUTE PROCEDURE a través de FunctionDesc y OperateFunctionArg. Añade pruebas específicas del parser y de Display para uno y varios argumentos de cadena ordenados, conservando los argumentos de declaración como tipos de datos; se considerará terminado cuando ambas formas se analicen y se vuelvan a representar correctamente.

Problem

PostgreSQL trigger execution arguments are literal string constants passed to the trigger function through TG_ARGV. The PostgreSQL parser currently routes the EXECUTE FUNCTION / EXECUTE PROCEDURE tail through FunctionDesc / OperateFunctionArg, whose arguments represent function declaration data types. As a result, a valid trigger argument is parsed as though it were a data-type declaration and fails at the first literal.

Observed with sqlparser = 0.62 and PostgreSqlDialect.

Minimal reproductions

CREATE TRIGGER t_audit
AFTER INSERT ON t
FOR EACH ROW
EXECUTE FUNCTION audit_row('api_key');

The legacy PostgreSQL spelling fails the same way:

CREATE TRIGGER t_audit
AFTER INSERT ON t
FOR EACH ROW
EXECUTE PROCEDURE audit_row('api_key');

Both report:

Expected: a data type name, found: 'api_key'

The corresponding zero-argument forms parse successfully:

EXECUTE FUNCTION audit_row();
EXECUTE PROCEDURE audit_row();

PostgreSQL accepts both complete trigger statements with the string argument.

Expected behavior

• Both trigger statements parse successfully under PostgreSqlDialect.
• The AST retains 'api_key' as an execution-time literal/expression (or a trigger-specific argument representation), not as an OperateFunctionArg data-type declaration.
• Multiple trigger arguments remain ordered and round-trip through Display.
• Function/procedure declaration arguments continue to use the existing data-type-oriented representation.

PostgreSQL's grammar requires trigger arguments here to be string constants. A trigger-specific argument field would therefore also be reasonable if using the general expression AST would accept syntax PostgreSQL itself rejects.

Downstream context

This was found in Goldziher/scythe#238. Scythe statically parses schema DDL to build a catalog. Triggers do not add catalog state, so scythe skips them after parsing; it still needs sqlparser to accept the valid statement so one trigger does not abort parsing of the entire schema.

I can prepare a focused parser/AST test or implementation once the preferred AST representation is confirmed.