Same sentiment here.
Its 2025, the necessity of the principle of least privilege is greater than ever.
I'm not installing random third-party postgres extensions. Even in dev environments. Sorry.
When selecting a linter, I'd just recommend ensuring the author(s) are deeply experienced in your particular DBMS. Otherwise they tend to cargo-cult bad advice that is either out-of-date, or only makes sense for some other DBMS. And nowadays, AI hallucinations are another source of nonsensical linters.
[1] https://www.skeema.io/docs/features/safety/
in theory, one should be able to extract the "rule" definitions [1] and have it run with a conn str; instead of this _needing_ to be an extension.
in practice though, query plan analysis and missing indexes is a bigger use-case; since it's bad queries that take down the db.. and i see no rules here to help with that.
[1] https://github.com/pmpetit/pglinter/blob/9a0c427fac14840a7d6...
Rules can either run queries against the DB (e. g. foreign key without index) or use our parser to check code SQL, PL/SQL, and pgSQL soon (naming standards, security and performance issues, etc.). We currently have over 280 rules [1]. The tool runs as a lange server during development or as a CLI so you can use it in your automations. Its more enterprise focused, an admin can create configurations that get applied to all developmers.
They usually end up expanding in scope into places they shouldn’t be. Consider also react linters, full of rules that shouldn’t always be blanket applied or create tons of pointless busywork.
My ORM will decide the naming of my database tables, thank you very much. It’s much more qualified than a linter, which should stay in its lane.
That said, i agree with you than some of the default rules may be bad. For example : B001 & T001 recommend primary keys, but it will effectively kill a TimescaleDB hypertable (primary keys are not recommended).
The exact rules for identifier case sensitivity vary across different DBMS, for example in Postgres it depends on whether quotes are used: https://www.postgresql.org/docs/current/sql-syntax-lexical.h...
Meanwhile for MySQL/MariaDB it depends on whether the underlying OS/filesystem is case-sensitive or not: https://www.skeema.io/blog/2022/06/07/lower-case-table-names...
And plenty of similarly weird behavior on other DBMS.
ORMs tend to be generic / multi-DBMS, and you shouldn't always assume your ORM's behavior is more qualified than a DBMS-specific linter.
For most of my recent projects I use Prisma with Postgres; Prisma tables by default are named like TableName, and yes - for actual Postgres SQL that means you need to wrap everything in double quotes if you do anything manually `SELECT * FROM "TableName"` because otherwise it won't work.
But that's never actually been an issue for me in some way? Compared to the immense benefits of having a well designed ORM (like Prisma), this linter doesn't seem useful to me at all. But maybe I'm missing something.
Or if you ever need to port software to multiple DBMS instead of just Postgres, then having mixed-case names is especially a minefield, since each DBMS handles this differently and very few handle things per the SQL standard in this particular area.
It's admittedly a slightly niche linter rule, and in my own schema management software (which includes a linter) I have this rule default to being disabled.
As a side note though, it's honestly a red flag when an ORM uses mixed-case names by default. Normally one benefit of ORMs is that they help with multi-DBMS portability, but this design choice absolutely does the opposite.
Older versions of pg let you create cases identifiers without quotes. I don’t care enough to look which ones.
https://sqlpey.com/sql/postgresql-identifier-case-sensitivit...
fljdin•4mo ago