PostgreSQL中左值为字面量、右值为列的IN运算符用法是否有问题？

我在使用IN运算符时用了非常规写法——把字面量放在左侧，列名放在右侧，用来替代传统的多OR条件：

传统写法：

(table1.id = 123 OR table2.id = 123 OR table3.id = 123)

我的写法：

123 IN (table1.id, table2.id, table3.id)

目前在PostgreSQL里能正常运行，但担心这种非通用写法没被数据库优化，想知道会不会引发问题。

兼容性问题 #

• 这种反向写法不属于SQL标准语法，虽然PostgreSQL支持，但MySQL、SQL Server等其他主流数据库大概率不兼容。如果以后需要迁移数据库，这段代码肯定要修改。

查询优化情况 #

• 在PostgreSQL里，查询优化器会把123 IN (table1.id, table2.id, table3.id)和对应的OR条件当成完全等价的逻辑处理，生成的执行计划几乎没区别。你可以用EXPLAIN ANALYZE分别跑两种写法，就能看到执行计划完全一致，优化器也能正常利用table1.id、table2.id、table3.id上的索引（如果有的话）。
• 除非IN列表里的列来自复杂的多表关联，那得确保关联逻辑本身没问题，但核心的匹配逻辑不会因为反向写法影响优化效果。

代码可读性问题 #

• 绝大多数开发者习惯的是列名 IN (值列表)的写法，反向写法会增加其他维护者的理解成本，尤其是不熟悉PostgreSQL特性的人，第一眼可能会误以为是语法错误。

总结 #

如果你的系统只基于PostgreSQL运行，这种写法本身不会有性能问题，但从跨库兼容性和代码可维护性的角度，更推荐用标准的OR条件写法，或者调整成符合通用认知的结构。

内容的提问来源于stack exchange，提问作者naviram