PostgreSQL支持用WITH CTE + INSERT ... RETURNING + jsonb_array_elements_text()一条SQL完成父表插入及子表批量关联，原子性强、并发安全：首CTE接收参数，第二CTE插入父表并RETURNING主键，第三CTE用LATERAL展开JSONB数组并转类型，最后INSERT子表，全程无需应用层循环或触发器。
能用一条 SQL 完成父表插入 + 子表批量关联，就别拆成多条语句或应用层循环。PostgreSQL 原生支持这种原子性写法，关键在 WITH CTE + RETURNING + JSONB 解析，不是靠触发器或存储过程。
用 WITH + RETURNING 获取刚插入的父表 ID
PostgreSQL 的 INSERT ... RETURNING 能立刻拿到新生成的主键，且这个值可在同一语句后续 CTE 中直接引用。这是实现“嵌套插入”的前提，比应用层查 LAST_INSERT_ID() 更安全、更并发友好。
-
RETURNING必须跟在 INSERT 之后，不能跨语句；它返回的是当前会话本次 INSERT 的结果集，不受其他事务干扰 - 如果父表主键是
SERIAL或GENERATED ALWAYS AS IDENTITY，RETURNING id就是唯一可靠方式 - 不要用
SELECT MAX(id)或currval()替代 —— 前者不安全，后者依赖序列名且在并行插入时可能错乱
用 jsonb_array_elements_text 批量展开子表数据
当子表关联数据来自数组（如 req.body.tags = [3, 4, 7]），直接拼 VALUES (1,3),(1,4),(1,7) 不仅麻烦，还容易被注入。PostgreSQL 的 jsonb_array_elements_text() 可把 JSON 数组转为行集合，天然适配批量插入场景。
- 输入必须是
jsonb类型，所以传参前要JSON.stringify()并用$1::jsonb显式转换 -
jsonb_array_elements_text()返回的是text，若子表外键是integer，需显式转成(t.elem)::int - 避免用
json_array_elements()—— 它返回jsonb，再取字段要多一层->>'id'，冗余且易错
CTE 链式写法确保原子性与顺序依赖
多个 CTE 按定义顺序执行，后一个可引用前一个的输出。用 WITH 把父表插入、ID 提取、子表展开、子表插入串成一条语句，整个操作要么全成功，要么全失败，不需要手动 BEGIN/COMMIT。
- 第一个 CTE（如
invars）用于安全接收外部参数，避免 SQL 注入 - 第二个 CTE（如
insert_notecard）执行父表插入并RETURNING notecard_id - 第三个 CTE（如
insert_tags）用CROSS JOIN LATERAL jsonb_array_elements_text(...)展开并关联 - 最后的
SELECT只是收尾返回状态，不参与写入；没这句，语句也能执行，但客户端拿不到计数
为什么不用 INSERT INTO ... SELECT + VALUES 嵌套？
PostgreSQL 允许在 VALUES 里写 (SELECT ...)，但只限单行单列标量。一旦子表数据是动态数组，这条路就走不通 —— VALUES (1, (SELECT unnest(ARRAY[3,4,7])) 会报错 “more than one row returned”。这不是语法糖能解决的量级问题。
-
INSERT ... SELECT是正路，但它要求子查询结果集结构和目标表严格对齐，而动态数组需要先“炸开”成行 - 用
UNNEST(ARRAY[...])也可行，但数组得硬编码或靠应用层拼接，失去参数化优势 - JSONB 方案把动态性留在数据库内：参数是纯字符串，解析逻辑完全由 SQL 控制，接口更干净
真正容易被忽略的是类型转换细节 —— jsonb_array_elements_text() 输出 text，而多数外键是 integer 或 uuid，漏掉 ::int 或 ::uuid 会导致类型不匹配错误，且错误信息往往只提示“column ‘x’ is of type integer but expression is of type text”，不会直接指出是 JSON 解析结果没转型。
