您永远不能排除bug的可能性，但在这种情况下，我也不会预先担心它们。我很惊讶地看到，当同一个表中有多个列时，使用BitmapOr的最明显的优化仍然应用于IN列表。（当它们不在同一个表中时，我不认为任何一种编写方式都能得到很好的优化。
我可能会避免这种编写方式，这是为了那些需要阅读我的代码的人，而不是为了计算机。但如果涉及的常数比“123”长得多，也许避免重复就值得非常规编码。

• 根据我的经验，使用IN操作符，左边是文字值，右边是列，这不是一种常见的用法，但它应该在大多数数据库系统中正常工作，包括PostgreSQL。数据库优化器应该能够有效地处理这种类型的查询。
• 在PostgreSQL中，IN操作符被设计为在右侧接受一个值列表或一个子查询。在您的例子中，您在右侧提供了列名，这是非常规的，但却是有效的。
• 只要您的查询返回预期的结果并且性能良好，那么以这种方式使用IN运算符应该不会有直接的问题或性能问题。
• 但是，值得注意的是，对于不熟悉这种非常规模式的其他开发人员来说，这种用法可能会降低SQL查询的可读性和直观性。通常建议遵循标准SQL实践，以获得更好的代码可维护性和协作。
• 如果您担心这种用法的性能或潜在问题，您可以考虑使用大型数据集测试查询，或者咨询数据库Maven，以评估特定于您的应用程序和数据库环境的任何潜在缺点。