PostgreSQL 在 WHERE 中引用 SELECT 列别名，报 column does not exist

查询里已经写了 email AS electronic_mail，加上 WHERE electronic_mail = '' 后却报错：

ERROR: column "electronic_mail" does not exist

例如，下面这条查询想筛出邮箱为空字符串的记录，并把输出列命名为 electronic_mail：

SELECT id, email AS electronic_mail
FROM app_users
WHERE electronic_mail = '';

如果输入表没有名为 electronic_mail 的列，就会遇到这个名称解析问题。这里的 app_users、id、email 是示例表名和列名，需按实际结构调整。本文针对 PostgreSQL，PostgreSQL 18 仍不允许在同层 WHERE 中使用输出别名。

输出列名不等于这一层查询的输入列

AS electronic_mail 给当前查询的输出列命名。当前层的 WHERE 条件引用的是输入表、连接或子查询提供的列，不能直接把同一层刚定义的输出别名当作输入列。

判断时，从发生错误的 WHERE 所在层向它的 FROM 看：这一层实际收到哪些列？如果收到的是 email，而 electronic_mail 只出现在同层的 SELECT 列表中，就应调整引用位置。

加双引号、给别名前加表别名，或者把表达式改成某个函数调用，都不会让同层输出列自动进入 WHERE 的可见范围。尤其不要为了让 SQL 通过而给业务表新增一个同名字段，这会改变数据结构，甚至让原查询静默地筛选另一个值。

可以把这理解为查询各部分的逻辑作用域，但不能据此断言数据库物理执行时一定先完整扫描、再完整计算某一层。查询优化器可以调整执行计划，名称可见性与具体执行顺序是两回事。

简单改名，条件里继续使用原列

如果只是重命名输出，最直接的修复是保留 SELECT 的别名，在条件里引用原列：

SELECT u.id, u.email AS electronic_mail
FROM app_users AS u
WHERE u.email = '';

这样筛选的是实际输入列 u.email，返回给应用的列名仍是 electronic_mail。对依赖结果字段名的程序来说，不需要为了修复筛选条件再改一遍输出接口。

若输出的是计算表达式，可在条件中写出对应表达式。例如，下式把两个普通数值列相乘，并筛选计算结果：

SELECT i.id, i.quantity * i.unit_price AS line_total
FROM invoice_lines AS i
WHERE i.quantity * i.unit_price >= 100;

这里假设 quantity 和 unit_price 已是可相乘的数值类型，100 是示例阈值。这种写法适合容易核对、没有副作用的简单表达式。不要为了少写一次表达式，就把筛选列换成一个意义不同的原始字段。

需要按别名筛选，把定义放到内层

表达式较长，或者查询本来就有子查询时，可以让内层输出这个别名，再由外层引用它：

SELECT q.id, q.electronic_mail
FROM (
    SELECT u.id, u.email AS electronic_mail
    FROM app_users AS u
) AS q
WHERE q.electronic_mail = '';

这时 electronic_mail 是子查询 q 对外提供的列，外层 WHERE 可以使用。关键是别名定义在内层；仅仅在原查询周围放一个没有提供该别名的子查询，并不能解决问题。

下面这种结构仍然不对：

SELECT q.id, q.email AS electronic_mail
FROM (
    SELECT id, email
    FROM app_users
) AS q
WHERE electronic_mail = '';

内层只输出 id 和 email，而别名仍定义在发生过滤的同一层。应把 AS electronic_mail 移到内层，或直接把条件改成 q.email = ''。

子查询在这里解决的是名称范围，不保证表达式只计算一次，也不保证产生中间临时表。涉及昂贵函数、易变函数或副作用时，应另外确认求值语义和执行计划，不能把“多包一层”当作固定的缓存机制。

ORDER BY 能用别名，不代表 WHERE 也能用

PostgreSQL 允许 ORDER BY 和 GROUP BY 引用输出列名，但 WHERE 和 HAVING 不具备同样规则。按别名排序成功，不能证明把这个名字复制到筛选条件中也合法。

聚合后的筛选应保留聚合语义。例如，统计每个客户的记录数并保留至少十条的客户：

SELECT customer_id, count(*) AS order_count
FROM sales_orders
GROUP BY customer_id
HAVING count(*) >= 10;

这里不能仅把末行改为 HAVING order_count >= 10。也不要把聚合条件搬到同层 WHERE，因为它处理的是分组前的行。若一定要按 order_count 这个输出名筛选，可将整个分组查询放到子查询里，再使用外层 WHERE。

还要避免输出别名与已有输入列重名。名称恰好能被解析时，SQL 可能不再报错，却筛选了输入列而非你预期的计算结果。为计算结果取不同的名字，并在条件里明确写出输入表别名，通常更容易发现这种混淆。

用固定数据核对筛选结果

可以在测试会话中使用以下独立示例理解查询层次。它用 VALUES 提供三行固定数据，不需要创建或修改业务表：

SELECT q.id, q.electronic_mail
FROM (
    SELECT u.id, u.email AS electronic_mail
    FROM (
        VALUES
            (1, ''::text),
            (2, 'reader@example.com'::text),
            (3, NULL::text)
    ) AS u(id, email)
) AS q
WHERE q.electronic_mail = '';

按这个条件推导，应只返回 id=1。空字符串和 NULL 不相同；缺失值那一行不会因为 = '' 而入选。如果业务同时需要两者，应明确改成空字符串条件与 IS NULL 条件的组合，并分别核对样本，不能顺手改变原来的筛选范围。

恢复到真实查询时，检查错误是否消失、输出字段名是否保留，以及命中记录是否符合原来的业务条件。仅确认 SQL 能运行不够，尤其要检查输入列与输出别名重名的情况。

此类修复通常只涉及查询文本。保留原 SQL 或应用版本，在小规模测试数据上对比后再上线；需要回退时恢复查询版本。不要为了绕过名称解析错误执行表结构变更，也不要把只读示例直接改成批量更新或删除来验证。