PostgreSQL 没有 Oracle 那种匿名 PL/SQL 块，但别担心——它提供了一个叫 DO 的语法糖，本质上就是一次性、无名的 PL/pgSQL 执行单元。这东西不创建对象，也不持久化，最适合临时逻辑或一次性数据处理。
不少开发者会踩的坑是：把 DO 当成函数调用塞进普通 SQL 里——比如写在 SELECT 或 INSERT 后面，这是不允许的。DO 块必须独立执行，整个块作为单条语句提交，不能加 CREATE OR REPLACE FUNCTION 那套修饰。块内变量作用域仅限块内，一退出就销毁，跨块共享变量？想都别想。如果非要传参，只能靠字符串拼接动态构造（不推荐），或者干脆改成带参数的函数。
DO块必须以分号结尾，psql 里注意反斜杠换行会中断解析- 变量生命周期短，无法跨
DO复用 - 示例：
DO $$ BEGIN RAISE NOTICE 'Hello from DO block'; END $$;
想复用逻辑？别硬塞 DO，优先写 FUNCTION
很多场景下，所谓的“匿名块调用”需求，说白了就是想临时封装一段可多次触发的逻辑。这时候 DO 反而成了绊脚石——没法传参、没法返回值、没法被其他函数调用。PostgreSQL 的函数本质上就是它的“可调用匿名块”，尤其是 LANGUAGE plpgsql 的函数，不仅能覆盖 DO 的所有能力，还更灵活。
- 函数支持
IN/OUT参数，类型检查和默认值一应俱全 - 可被
SELECT、PERFORM、其他函数直接调用，甚至参与事务控制 - 定义后存在系统目录中，用
df就能查，比DO更容易调试和复用 - 示例：
CREATE OR REPLACE FUNCTION log_and_update(id INT) RETURNS VOID AS $$ BEGIN RAISE NOTICE 'Processing %', id; UPDATE users SET updated_at = NOW() WHERE user_id = id; END $$ LANGUAGE plpgsql;
调用方式：SELECT log_and_update(123);或PERFORM log_and_update(123);
存储过程（PROCEDURE）不是万能替代，注意事务边界
PostgreSQL 12+ 引入了 PROCEDURE，它和函数的关键区别在于：能在内部执行 COMMIT/ROLLBACK，但不能出现在 SELECT 中，也不能返回值。只有在需要手动控制事务（比如批量导入中途提交）时，才值得用 PROCEDURE。
误用的话就会碰到这类报错：ERROR: cannot execute COMMIT in a read-only transaction 或 ERROR: procedures cannot be used in SELECT。
- 唯一合法调用方式是
CALL，例如：CALL my_procedure(456); - 内部若含 DML，必须显式声明
LANGUAGE plpgsql，并确保 session 处于可写状态 - 过程不能像函数那样被嵌套在表达式里，也不支持
RETURNS TABLE等返回机制 - 如果只是想“执行一段逻辑”，函数 +
PERFORM通常就够了，别为了“听起来更正式”硬上PROCEDURE
动态 SQL 是绕不开的坎，但 EXECUTE 必须配 USING 防注入
不管是 DO、函数还是过程，只要涉及拼表名、字段名或不确定结构的查询，就得用 EXECUTE。但直接字符串拼接等于敞开 SQL 注入大门。PostgreSQL 对此有明确要求：表名/列名等标识符必须用 format() + %I 占位符处理；运行时值必须走 USING 子句传参。
- 错例：
EXECUTE 'UPDATE ' || table_name || ' SET val = ' || value;——value未转义，table_name未校验 - 对例：
EXECUTE format('UPDATE %I SET status = $1 WHERE id = $2', tbl_name) USING new_status, record_id; %I自动加双引号并转义，$1/$2由USING绑定，类型安全- 漏掉
USING或错用%L（用于字面量）都可能引发类型不匹配或注入漏洞
实际写下来，多数所谓“匿名块需求”落地就是一个带参数的 FUNCTION；只有极少数涉及事务拆分或跨会话状态管理，才需要碰 PROCEDURE。而 DO 块，基本只留给一次性调试或部署脚本里的临时逻辑——用对地方，事半功倍。
