Why this matters
`column IN (subquery)` returns NULL whenever the subquery yields a NULL row, which silently filters every row from the outer query. `EXISTS (subquery)` returns a clean boolean and is typically planned more cheaply too. Literal `IN` lists (`x IN (1, 2, 3)`) are out of scope.
Examples
Incorrect
SELECT * FROM t WHERE x IN (SELECT id FROM other);SELECT * FROM t WHERE x = ANY (SELECT id FROM other);Correct
SELECT * FROM t WHERE EXISTS (SELECT 1 FROM other WHERE other.id = t.x);SELECT * FROM t WHERE x IN (1, 2, 3); -- literal list is out of scopeConfigure it
// eslint.config.js
import postgresql from "eslint-plugin-postgresql";
export default [
{
files: ["**/*.sql"],
languageOptions: {
parser: postgresql.configs.recommended.languageOptions.parser,
},
plugins: { postgresql },
rules: {
"postgresql/prefer-exists-over-in-subquery": "warn",
},
},
]; Options
Edit the SQL — only prefer-exists-over-in-subquery is enabled.
Pre-filled with the first incorrect example. Toggle off in the rule shelf to see how the diagnostic disappears.
Diagnostics
No issues found.
2 rules enabled.
Rule under test
prefer-exists-over-in-subquery — plus no-syntax-error as a safety net.