pgvector 本身不提供文本向量化函数，触发器中无法直接调用；必须由应用层或etl预计算向量后传入，触发器仅负责基于字段变更（如 new.text is distinct from old.text）安全赋值 new.embedding := ...，维度需严格匹配且避免在after中更新以防递归。
触发器里怎么调用 pgvector 的向量化函数
PostgreSQL 本身不内置文本转向量能力，必须依赖外部模型（如 sentence-transformers）预计算，或用 pgvector 配合 plpython3u 等过程语言调用 Python。直接在 SQL 触发器里调用 OpenAI 或 Hugging Face API 不现实——超时、网络不可靠、事务阻塞风险高。所以实际路径只有一条：向量必须提前算好传入，触发器只负责「搬运」和「更新」。
常见错误是试图在 BEFORE INSERT OR UPDATE 触发器里写 SELECT embedding_model(text)——这函数根本不存在，PostgreSQL 不认识任何嵌入模型。
- 真正可用的是
vector类型字段 + 应用层/ETL 层生成向量后写入 - 若坚持在 DB 内完成，需启用
plpython3u并安装transformers和torch（生产环境极不推荐） - 更稳妥做法：触发器只检查
text_content是否变更，若变则清空embedding字段，由外部服务监听pg_notify或轮询 dirty 标志位来异步补全
触发器如何判断是否需要更新向量字段
全文检索场景下，向量更新不能无条件执行——哪怕只是改了个标点，也不该触发重嵌入（成本高、没必要）。关键在于识别「语义相关变更」，但数据库没语义理解能力，只能退而求其次做「字段值变更检测」。
- 用
NEW.text_column IS DISTINCT FROM OLD.text_column判断是否真有内容变化（比!=更安全，能处理 NULL） - 避免对
updated_at、status这类元字段更新连带触发向量重算 - 如果表有多个文本字段（如
title+body），建议拼接后哈希比对：md5(NEW.title || ' ' || NEW.body) != md5(OLD.title || ' ' || OLD.body) - 注意：
tsvector字段本身可被触发器监听，但那是倒排索引，不是向量；别把它和vector混用
触发器函数里怎么安全写入 vector 字段
pgvector 的 vector 类型支持直接赋值，但维度必须严格匹配。触发器里硬编码维度（如 [384]）极易出错——模型一换，全挂。
- 建表时用
embedding vector(384)明确维度，触发器里就老实用NEW.embedding := ...赋值，别试图动态 reshape - 插入空向量用
'{}'::vector或array_fill(0.0, ARRAY[384])::vector，别用NULL（否则ORDER BY embedding query_vec会跳过该行） - 如果应用层传来的向量是 base64 或 float32 字节数组，触发器无法解码——必须在应用侧转成 PostgreSQL 支持的格式（如逗号分隔字符串
'0.1,0.2,-0.3'）再入库 - 不要在触发器里做归一化（
normalize()），那属于查询时操作；写入即存原始向量
为什么不能用 AFTER 触发器更新向量
看起来 AFTER 更“自然”：等主记录落库后再更新向量。但问题在于——向量字段通常和主文本在同一张表，AFTER 触发器无法修改 NEW 行（已提交），只能发通知或写日志，起不到同步更新作用。
-
BEFORE是唯一能在同一事务中修改即将插入/更新行的方式 - 若向量存在另一张关联表（如
document_embeddings），那可以用AFTER+INSERT ... ON CONFLICT更新，但会引入额外 JOIN 开销 - 最常踩的坑：在
AFTER里执行UPDATE documents SET embedding = ... WHERE id = NEW.id—— 这会触发新一轮触发器，导致无限递归（除非加IF NOT TG_OP = 'UPDATE'检查）
向量更新这件事，本质是数据写入流程中的一环，不是事后补救。把计算逻辑推到应用层、把一致性保障交给事务边界，比在数据库里堆胶水代码更可控。
