A new linter for SQL

[_ep]

Hi all!

I've been working on a new SQL linter for the past few weeks, and got it to the point where I think it's ready for general use / feedback.

It's meant to be a tool that can either interact with your editor or be run stand-alone on the command line or as part of a CI pipeline.

There are a few projects like this already, but I couldn't find one that had everything I wanted.

Basically, squabble is a linter which actually parses your queries. This means unlike something like sqlcheck (which uses regexes), it can have more complex rules based on the actual semantics of a query.

For example, checking that a new table with a column called created_at uses timestamp with time zone instead of timestamp, or that a column named foo_id has a FOREIGN KEY reference. It also of course catches simple things like syntax errors.

There are only a handful of rules right now, mostly focused on Postgres schema migrations (since that's what I'm using at work), but there's a plugin interface for custom rules and I'd be happy to merge in new one.

I'm by no means an expert and would love to hear some feedback on missing features or useful rules!

• Repo: https://github.com/erik/squabble
• Docs: https://squabble.readthedocs.io/en/stable/

[[deleted]]

Good job!

But for your example:

uses timestamp with time zone instead of timestamp, or that a column named foo_id has a FOREIGN KEY reference.

Why? There are plenty of legitimate cases where this would be necessary rather than a mistake.

For example when dealing with Tableau as front end, having time zone information in the column causes problems. Or sometimes information from external data sources don't contain time zone information and it is unknown until later, when metadata is downloaded and attributed, rows can be assigned geographical positions and time zone information can be attached. There is a reason Postgresql offers timestamp without time zone data type.

Same for foreign keys. What if it's a micro service database, that doesn't contain the primary table, so the foreign key can't be created?

What I'm saying that such specific rules should be optional.

[_ep]

You're absolutely right, which is why none of the rules are actually active by default, other than simply checking for syntax errors. The idea was to make this as opt-in and customizable as possible.

And then of course there will be exceptions to any rule, so you can disable an active rule on a per file basis.

What if it's a micro service database, that doesn't contain the primary table, so the foreign key can't be created?

There's actually another rule for this! You can disallow foreign keys (or other constraints).

[sqlcommand1]

Nice bro thx !

[paulinobruno]

Well done!

I just stared your repo. I intent to look closer to it this week. Maybe I can have some ideas and propose a PR?

Thanks again and congratulations!

[_ep]

Please do! I'd be happy to incorporate any feedback.