PostgreSQL 在 SET 左侧使用表别名，报 column does not exist

把更新语句迁移到 PostgreSQL 后，表和业务列都存在，错误却说表别名对应的“列”不存在。例如，假设 inventory 已有 item_id 和 quantity 两列：

UPDATE inventory AS i
SET i.quantity = 0
WHERE i.item_id = 1001;

可能得到这样的错误：

ERROR: column "i" of relation "inventory" does not exist

要修改的是 quantity，错误却指向 i。这里应先检查 SET 等号左侧的写法：PostgreSQL 的更新目标列不能加目标表名或表别名前缀。保留表别名，只删除赋值目标前的 i.：

UPDATE inventory AS i
SET quantity = 0
WHERE i.item_id = 1001;

PostgreSQL 18 仍采用这项规则。它针对赋值目标列，不代表 UPDATE 不支持表别名，也不代表所有 column does not exist 都能这样处理。下面的表名、列名和编号均为示例，实际变更前应核对目标表、条件和影响行数。

等号左侧与右侧的语法不同

UPDATE inventory AS i 已经确定要更新的目标表。SET quantity = ... 的左侧直接指定这张表的目标列，无须再用别名限定。

等号右侧是表达式，可以引用更新前的列值；WHERE 也可以使用别名限定列。因此，下面这种写法是有意义的：

UPDATE inventory AS i
SET quantity = i.quantity + 5
WHERE i.item_id = 1001
RETURNING i.item_id, i.quantity;

左侧是 quantity，右侧是 i.quantity + 5，两者不需要写成同一种形式。RETURNING 这里返回实际被更新行的新值，便于检查匹配的编号和结果。

给目标表设置别名后，后续引用应使用该别名。不要一边写 UPDATE inventory AS i，一边又在表达式或条件中改用 inventory.quantity，否则还会遇到另一类名称解析问题。

如果错误确实指向业务列本身，而不是出现在赋值左侧的别名，则继续核对列名、双引号大小写以及目标表是否正确。不要为了消除报错创建一列名为 i 的字段，也不要把 i.quantity 整体加双引号当作修复：那会表达一个包含点号的列名，改变原本的含义。

在本机用独立临时表检查修正结果

下面是一份完整的本机测试示例。请在测试数据库的新会话中阅读并按需运行，不要把测试替换成生产表。示例先建临时表、放入两行数据，在事务内检查更新结果，最后回滚整个事务：

BEGIN;

CREATE TEMP TABLE demo_set_alias_inventory (
    item_id integer PRIMARY KEY,
    quantity integer NOT NULL
);

INSERT INTO demo_set_alias_inventory (item_id, quantity)
VALUES (1001, 10), (1002, 20);

SELECT i.item_id, i.quantity
FROM demo_set_alias_inventory AS i
WHERE i.item_id = 1001;

UPDATE demo_set_alias_inventory AS i
SET quantity = i.quantity + 5
WHERE i.item_id = 1001
RETURNING i.item_id, i.quantity;

SELECT item_id, quantity
FROM demo_set_alias_inventory
ORDER BY item_id;

ROLLBACK;

预期更新返回一行，编号为 1001、数量为 15；随后查询的两行分别是 1001 / 15 和 1002 / 20。后一行用于确认更新没有越过指定条件。这些是示例的验收预期，不应只把“SQL 不再报错”当作通过。

该示例以 ROLLBACK 结束，不提交测试变化。若中途语句出错，先回滚这次独立测试事务，再检查错误；不要在已有业务事务中随意执行回滚。客户端可能自行管理事务，使用前应确认其执行方式。

真实更新中的加法会累加，重复执行不等于重新检查。排错时先用同样的条件查询目标行，再决定是否执行更新；不要靠反复点击执行来确认语法。

从其他表取值时，只去掉赋值目标的前缀

如果更新值来自另一张表，别名还能避免表达式和关联条件中的歧义。假设 inventory_adjustment.item_id 对每个商品最多有一条调整记录，可使用以下结构：

UPDATE inventory AS i
SET quantity = a.new_quantity
FROM inventory_adjustment AS a
WHERE i.item_id = a.item_id
  AND i.item_id = 1001
RETURNING i.item_id, i.quantity;

这里仅左侧 quantity 不带别名，右侧 a.new_quantity 和条件中的别名都保留。不要为修复这个错误，把整个 SQL 里的 i.、a. 全部删除；存在同名列或相关子查询时，这可能制造歧义，甚至改变条件引用的对象。

这份结构有一个独立前提：每条目标记录最多匹配一条来源记录。若来源表对同一商品有多条匹配，UPDATE ... FROM 可能选用其中某一条，不能据此保证更新值是哪一个。应先检查关联结果及唯一性，不能把修好左侧别名误认为整条更新已经可靠。

目标表已经写在 UPDATE 后，通常不需要再把它重复放入 FROM。只有明确要做自连接时，才为那份额外的表引用另设别名和关联条件。

SET 左侧的点号也可能是合法的复合字段路径

不能把这个规则简单归纳为“SET 左边不允许点号”。PostgreSQL 支持更新复合类型列的某个子字段。假设表中确实有一个复合类型列 dimensions，其中包含 width 字段，左侧可以写成 dimensions.width。

在这种语法位置，点号前面表示要更新的列，后面表示该列内部的字段，并不是表别名。也正因为需要按这种语法解析，SET i.quantity = ... 会让 PostgreSQL 尝试寻找名为 i 的目标列，从而出现开头那条错误。

迁移工具应识别赋值目标、表达式引用和复合字段路径，不能只用全局字符串替换删除点号前缀。普通字段去掉表别名即可；真实复合字段的路径需要保留。

应用到业务查询前保留回退条件

保存修改前的 SQL 或查询生成模板，并用本机样本核对更新行数、主键集合和新值。RETURNING 没有返回行可能只是条件没有匹配，不等于语法修复失败；返回多行时则应停下来复查筛选条件。

发布查询代码的回退与数据回退是两件事。恢复旧模板可以停止继续使用新查询，但已经提交的数据变化不会随代码回退而恢复。真实写入前应按既有流程保留必要的旧值或备份；发现误更新时，不要随意执行反向加减来“抵消”，尤其是在可能有并发更新的情况下。