Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

PostgreSQL CREATE TRIGGER parses execution arguments as data types

オープン
  • 何か問題がありますか？
#2,446 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
postgresql, rust
領域
compilers, databases

調査の方向性

PostgreSqlDialect のトリガー解析から始め、FunctionDesc と OperateFunctionArg を通る EXECUTE FUNCTION および EXECUTE PROCEDURE のパスを追跡します。1 つおよび複数の順序付き文字列引数を対象とする parser と Display の集中的なテストを追加し、宣言引数をデータ型として保持します。両方の形式を正常に解析してラウンドトリップできれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
3.5k
フォーク
780
平均マージ
4日 6時間
マージ済み PR（30日）
56

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/datafusion-sqlparser-rs のほかの issue

apache/datafusion-sqlparser-rs の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。