可以，delete returning 能原子性返回被删行的原始值快照，包括主键、时间戳、json字段等任意列，支持表达式和函数计算，但不可引用已删除表的别名。
DELETE RETURNING 能否真正返回被删行的原始值？
可以，而且是原子操作——DELETE 执行的同时，RETURNING 就能拿到被删行的完整快照，包括主键、时间戳、JSON 字段等任意列。这不是“查完再删”的模拟，而是 PostgreSQL 在执行删除前就锁定并捕获了这些值。
常见误用是以为 RETURNING 只能返回主键或常量，其实它支持表达式、函数调用甚至子查询（只要不引用已删除的表别名）。
- 必须写在
DELETE语句末尾，紧接WHERE子句之后 - 不能在没有
WHERE的DELETE FROM table;中省略条件，否则会返回全部行（可能触发锁或 OOM） -
RETURNING *是合法的，但生产环境建议明确列出字段，避免因表结构变更导致下游解析失败
如何安全地用 RETURNING 获取 JSON 或计算字段？
PostgreSQL 允许在 RETURNING 中使用任意标量表达式，比如把几列拼成 JSON 对象、格式化时间、或调用 md5() 做校验。关键点在于：所有表达式都基于删除前的行值计算，不会受并发修改影响。
例如，你想归档被删订单的摘要信息：
DELETE FROM orders WHERE status = 'cancelled' AND created_at
- 若某列可能为
NULL，json_build_object()会忽略该键；需用jsonb_build_object()+COALESCE控制输出 - 避免在
RETURNING中调用写入函数（如nextval()），虽然语法允许，但逻辑上不合理 - 如果要返回大对象（
BYTEA或长文本），注意客户端是否限制单行返回长度
为什么 RETURNING 有时返回空结果，但行确实被删了？
最常见原因是 WHERE 条件匹配了行，但触发器（尤其是 BEFORE DELETE）中用 RETURN NULL 抑制了删除——此时 RETURNING 不触发，因为实际没删任何行。
其他可能性：
- 事务未提交，另一会话查不到，但本会话
RETURNING仍应有结果（除非被触发器拦截） -
WHERE条件用了 volatile 函数（如random()），导致执行时条件不成立 - 权限不足：用户有
DELETE权限但无SELECT权限，而RETURNING隐式需要读取列值——会报错permission denied for table xxx
与应用层“先查后删”相比，RETURNING 的真实代价是什么？
性能上几乎无额外开销：PostgreSQL 在执行删除的同一扫描过程中就把所需列值存入结果集，不增加磁盘 I/O 或索引查找次数。但要注意内存占用——RETURNING 的结果集会暂存在 backend 内存中，直到客户端 fetch 完。
典型陷阱：
- 批量删除数万行并
RETURNING *，可能导致内存暴涨或网络缓冲区溢出 - 在 PL/pgSQL 函数里用
GET DIAGNOSTICS只能拿到行数，拿不到数据；必须用RETURNING+INTO或游标 - 某些 ORM（如 Django ORM）默认不暴露
RETURNING结果，需手写 raw SQL 或启用特定选项（如 SQLAlchemy 的returning()方法）
真正容易被忽略的是隔离级别交互：在 REPEATABLE READ 下，RETURNING 返回的仍是本事务视角的旧值，但如果其他事务刚更新了同一行，你的 WHERE 可能因谓词重检而跳过它——这和普通 DELETE 行为一致，但开发者常误以为 RETURNING 会“绕过”MVCC 规则。
