postgresql/consistent-create-index-concurrently

Why this matters

Two valid stances exist: (a) always use `CREATE INDEX CONCURRENTLY` so the build avoids the table-level `SHARE` lock and doesn't block writers, or (b) never use it so each `CREATE INDEX` can run inside a migration transaction. Pick one with the `style` option. Off by default because the right answer depends on your migration framework.

Examples

CREATE INDEX idx_users_email ON users (email);

CREATE INDEX CONCURRENTLY idx_users_email ON users (email);

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/consistent-create-index-concurrently": [
        "warn",
        {
          style: "always",
        },
      ],
    },
  },
];

Options

style "always" | "never" default: "always"

Which stance to enforce. `always` (default) requires `CONCURRENTLY` so the build doesn't block writers. `never` forbids it so each `CREATE INDEX` can run inside a migration transaction.