All rules

Schema

postgresql/consistent-text-over-varchar

Enforce a consistent stance on `text` vs `varchar(n)`.

  • Type suggestion
  • Recommended warn
  • Fixable no

Why this matters

PostgreSQL stores `text` and `varchar(n)` the same way. The length on `varchar(n)` is enforced by a per-table constraint that you cannot relax without rewriting the table. Use `text` with a `CHECK (length(col) <= N)` when you need a cap. Or invert the rule with the `style` option for projects that intentionally cap every string column at the type level.

Examples

Incorrect

Incorrect
CREATE TABLE users (name VARCHAR(255));

Correct

Correct
CREATE TABLE users (name TEXT);
Correct
CREATE TABLE users (name TEXT CHECK (length(name) <= 255));

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-text-over-varchar": [
        "warn",
        {
          style: "always",
        },
      ],
    },
  },
];

Options

style "always" | "never" default: "always"
`always` (default) requires `text` over `varchar(n)`. `never` requires `varchar(n)` (or another bounded string type) over `text`.
Try this rule

Edit the SQL — only consistent-text-over-varchar is enabled.

Pre-filled with the first incorrect example. Toggle off in the rule shelf to see how the diagnostic disappears.

0 errors 0 warnings parse 0ms · rules 0ms
Diagnostics

No issues found.

2 rules enabled.

Rule under test consistent-text-over-varchar — plus no-syntax-error as a safety net.
eslint-plugin-postgresql

An ESLint plugin that lints .sql files with real PostgreSQL grammar and a curated set of best-practice rules.

© 2026 eslint-plugin-postgresql contributors Built on libpg-query · PostgreSQL 17