在触发器中必须用PERFORM pg_notify('channel','payload')发送通知，不可直接写NOTIFY命令；因NOTIFY是SQL命令而非函数，不能在PL/pgSQL中执行，否则报错。
直接结论：在触发器中用 pg_notify() 是最稳妥的方式，不能用裸 NOTIFY 命令；通知内容必须是 TEXT 类型，超长或含二进制数据会静默失败。
为什么触发器里不能写 NOTIFY channel, 'msg'
因为 NOTIFY 是 SQL 命令，不是函数，无法在 PL/pgSQL 函数体中直接执行。PL/pgSQL 只允许在 PERFORM 或 SELECT 中调用函数，而 NOTIFY 不符合这个语法约束。
常见错误现象：ERROR: syntax error at or near "NOTIFY" 或触发器编译失败。
- 正确做法只能是
PERFORM pg_notify('channel_name', payload_text) -
pg_notify()是内置函数，返回VOID，所以用PERFORM忽略结果 - 它对事务安全：如果触发器所在事务回滚，通知自动丢弃
payload 怎么构造才可靠
payload 是 TEXT，不是 JSON 类型，即使你传入 json_build_object(...)，也必须显式转成文本，否则报错 cannot cast type json to text。
使用场景：需要传递结构化信息（如变更的主键、操作类型、时间戳）给监听端。
- 推荐写法：
json_build_object('op', 'INSERT', 'id', NEW.id, 'ts', NOW())::text - 避免拼接字符串：
'{"id":' || NEW.id || '}'—— 容易被注入或格式损坏 - 注意长度限制：PostgreSQL 9.0+ 的 payload 上限是 8000 字节，超长会被截断且无警告
- 不要传
bytea或大字段（如NEW.content），先做摘要或只传 ID
LISTEN 之后为什么收不到通知
监听端收不到，绝大多数情况不是触发器问题，而是客户端连接未启用“通知接收模式”或事务阻塞了消息投递。
性能 / 兼容性影响：LISTEN 是会话级命令，每个连接需单独执行；通知实际投递发生在事务提交后，且仅在下一次查询时由驱动批量拉取。
- Java/JDBC 必须调用
PGConnection.getNotifications()主动轮询，不是事件回调 - psql 中执行
LISTEN channel_x;后，必须再执行任意查询（如SELECT 1;）才能刷出消息 - Python 的
psycopg2需设置conn.poll()并检查conn.notifies，不能依赖自动推送 - 若监听端正在一个长事务中（比如
BEGIN; ...未提交），通知会卡住直到事务结束
最容易被忽略的一点：NOTIFY 不跨数据库生效。你在 db_a 里 pg_notify()，只有连到 db_a 并执行过 LISTEN 的客户端才能收到——哪怕它们用的是同一个 PostgreSQL 实例、同一个用户、同一个 host。
