Why this matters
PostgreSQL invents a name for unnamed constraints, but the generated name varies subtly across environments and migration tools, which makes later `DROP CONSTRAINT` / `ALTER CONSTRAINT` statements brittle. Column-level `NOT NULL` and `PRIMARY KEY` are allowed without explicit names.
Examples
Incorrect
CREATE TABLE items (id int, code text, UNIQUE (code));ALTER TABLE items ADD CHECK (length(code) > 0);Correct
CREATE TABLE items (
id int,
code text,
CONSTRAINT items_code_unique UNIQUE (code)
);ALTER TABLE items ADD CONSTRAINT items_code_non_empty CHECK (length(code) > 0);Configure 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/require-named-constraint": "warn",
},
},
]; Options
Edit the SQL — only require-named-constraint 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
require-named-constraint — plus no-syntax-error as a safety net.