PL/pgSQL的IF语句必须以END IF显式闭合，ELSIF为单个关键词且可连续使用，每个分支语句须以分号结尾；CASE是表达式，可用于SELECT，而IF是语句块，仅限BEGIN...END内执行。
PL/pgSQL 的 IF 语句必须配对使用 END IF，不能省略；ELSIF（不是 ELSEIF 或 elif）可连续写多个，但每个分支都必须以分号结束。
IF-THEN-ELSE 必须显式写完所有分支结构
很多人在写 IF 时只写了 IF ... THEN，漏掉 END IF，导致函数创建失败，报错类似：ERROR: syntax error at or near "END" 或 ERROR: expected END IF, but found ...。PL/pgSQL 不像 Python 靠缩进，也不像 SQL 标准的 CASE 可省略 ELSE —— 每个 IF 块都强制要求闭合。
常见写法要点：
-
IF后面不加冒号（:），直接跟布尔表达式 -
THEN和ELSE后面不能跟分号，语句写在它们之后、下个关键字之前 - 每个分支内的语句必须用分号结尾，包括
RAISE NOTICE、UPDATE、SELECT INTO等 -
END IF是一个完整关键词，中间不能换行或加空格
正确示例：
IF input_id > 0 THEN
SELECT name INTO v_name FROM users WHERE id = input_id;
IF NOT FOUND THEN
RAISE NOTICE 'user not found';
END IF;
ELSE
RAISE NOTICE 'input_id must be positive';
END IF;多条件判断优先用 ELSIF 而非嵌套 IF
当有三段以上逻辑（比如“小于10”“在10–20之间”“大于20”），用嵌套 IF 容易缩进混乱、漏写 END IF，且可读性差。直接用 ELSIF 更安全、更贴近自然语言逻辑。
注意点：
-
ELSIF是单个词，不是ELSE IF（后者会被解析为ELSE后接一个新IF块，需额外END IF） - 所有
ELSIF分支共享同一个END IF，不各自闭合 -
ELSE是可选的，但如果省略，而所有条件都不满足，会静默跳过 —— 这可能掩盖逻辑漏洞
对比错误写法（ELSE IF）：
-- ❌ 错误：这实际是 IF → ELSE → 新 IF，需要两个 END IF IF x < 10 THEN ... ELSE IF x < 20 THEN -- 这里解析为 ELSE 后跟一个独立 IF ... END IF; -- 只闭合了内层 IF，外层还缺一个 END IF
正确写法：
IF x < 10 THEN RAISE NOTICE 'small'; ELSIF x < 20 THEN RAISE NOTICE 'medium'; ELSE RAISE NOTICE 'large'; END IF;
CASE 和 IF 在性能与语义上的关键区别
表面上 CASE 和 IF-ELSIF 都能做多路分支，但底层行为不同：前者是**表达式**（可出现在 SELECT 列表、RETURN 中），后者是**语句块**（只能在 BEGIN ... END 内执行）。
这意味着：
- 你不能在
SELECT里直接用IF，但可以用CASE WHEN ... THEN ... ELSE ... END -
CASE的WHEN子句必须返回布尔值（CASE WHEN x > 0 THEN ...），而简单CASE（CASE x WHEN 1 THEN ...）只支持等值比较，不支持范围或IN - 如果没匹配到任何
WHEN且没写ELSE，CASE抛出CASE_NOT_FOUND异常；IF则只是跳过全部分支，不报错
所以：需要在 SQL 表达式中做分支 → 用 CASE；需要执行多条语句（如先 UPDATE 再 INSERT）→ 用 IF。
常见陷阱：FOUND 变量和 NULL 比较要小心
很多新手用 IF my_var = NULL THEN 判断空值，结果永远不进分支 —— 因为在 SQL 中 NULL = NULL 返回 NULL（不是 TRUE）。正确写法是 IF my_var IS NULL THEN。
另一个高频坑是依赖 FOUND：它只反映**上一条 SQL 语句是否返回行**，且仅在 SELECT INTO、GET DIAGNOSTICS 等少数语句后更新。如果你在 IF 前插了一条 RAISE NOTICE 或赋值语句，FOUND 就可能被覆盖为 FALSE。
安全做法：
- 紧挨着
SELECT INTO后立刻检查FOUND - 把
FOUND结果存进布尔变量再用，比如v_found := FOUND; - 避免在
IF块中混用多个查询，除非你明确知道FOUND被谁改写了
例如：
SELECT * INTO v_row FROM orders WHERE id = input_id; IF NOT FOUND THEN -- ✅ 紧接着用，安全 RAISE EXCEPTION 'order % not exists', input_id; END IF;
复杂逻辑里，IF 的嵌套层级、FOUND 的时效性、ELSIF 的拼写一致性，这三点最容易在调试时卡住 —— 不是语法错，而是行为不符合预期。写完先跑几个边界值（NULL、0、负数、不存在的 ID），比看文档更快暴露问题。
