It’s a good idea, but this kind of thing is my problem with linters: “B006: Tables with uppercase names/columns”
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.
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.
Sure, it depends on the circumstances of the project and company. If your company has software written in multiple languages interacting with the same database, then you're not all going through the same ORM and things like this can be problematic. That means it's useful to have a policy of "all identifiers should be lowercase", and the linter helps enforce that.
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.
It look like easy to disable a rule : `SELECT pglinter.disable_rule('B006');`.
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 reason you don’t this in psql is that for some versions of Postgres case is significant and you need to use quotation marks. I ran into this at one point and it drove me bonkers.
Older versions of pg let you create cases identifiers without quotes. I don’t care enough to look which ones.
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.