postgresql触发器函数不能定义输入参数，必须声明为returns trigger；其运行时参数通过只读全局数组tg_argv传递，索引从0开始，需手动类型转换且须校验长度。
触发器函数不能直接接收 SQL 层面的参数
PostgreSQL 触发器函数声明时必须是 RETURNS trigger，且**不能定义任何输入参数**（比如 CREATE FUNCTION f(x INT) RETURNS trigger 是非法的）。这是硬性限制，不是风格建议。你看到的 TG_ARGV 不是函数参数，而是 PostgreSQL 在调用触发器函数时自动注入的全局数组变量，它只在函数体内可用。
TG_ARGV 是什么，怎么安全使用
TG_ARGV 是一个 text[] 类型的数组，内容来自 CREATE TRIGGER 语句中 EXECUTE PROCEDURE function_name(arguments) 的 arguments 部分。它不是动态传入的，而是在创建触发器时就固化下来的字符串列表。
- 索引从 0 开始，
TG_ARGV[0]对应第一个字符串，TG_ARGV[1]是第二个，以此类推 - 所有值都是
text类型，需手动转换：比如TG_ARGV[0]::INT或TG_ARGV[1]::VARCHAR(50) - 访问越界会报错：
array subscript out of bounds，务必先检查array_length(TG_ARGV, 1) - 不要依赖空格或特殊字符分隔多个值——每个
argument是独立字符串，PostgreSQL 不做解析
示例：
CREATE OR REPLACE FUNCTION log_insert_with_tag() RETURNS trigger AS $$ BEGIN IF array_length(TG_ARGV, 1) <h3>为什么不能在运行时“动态传参”给已有触发器</h3> <p>触发器绑定的是固定函数和固定参数列表，<code>TG_ARGV</code> 的内容在 <code>CREATE TRIGGER</code> 时写死，后续无法修改，除非 <code>DROP</code> 再重建。这意味着：</p>
- 你无法在
INSERT INTO sales_data ...时临时塞一个用户 ID 进去 -
TG_ARGV不是上下文变量，不随每行数据变化；它对整个触发器实例全局有效 - 想实现“每行不同参数”，得靠
NEW或OLD记录里的字段，而不是TG_ARGV - 若真需要运行时参数，应改用普通函数封装逻辑，由应用层或存储过程显式调用
容易被忽略的关键细节
TG_ARGV 看似简单，但实际踩坑点很隐蔽：
- 字符串里带单引号？必须双写：
EXECUTE PROCEDURE f('user''s_name')，否则语法错误 - 参数含空格或逗号？没问题，PostgreSQL 按字面量原样存入
TG_ARGV，无需额外转义 - 触发器函数被多个触发器复用？
TG_ARGV值取决于各自CREATE TRIGGER的写法，不是共享状态 - 在
BEFORE行级触发器中修改NEW字段时，别误把TG_ARGV当成可变上下文——它不可赋值，只能读
真正需要动态上下文的地方，优先用 NEW.column_name 或 current_setting('app.custom_id', true) 配合 SET LOCAL，而不是强行塞进 TG_ARGV。
