3 ms·
> I am regularly surprised how bad the tooling is for SQL/databases. This. I'd really like to have a working SQL pretty printer/formatter. Psql is great, but
by mbork_pl 3y ago
> I am regularly surprised how bad the tooling is for SQL/databases.
This. I'd really like to have a working SQL pretty printer/formatter. Psql is great, but lacks autocompletion in several places.
That said, a big shoutout to pspg (https://github.com/okbob/pspg https://github.com/okbob/pspg) - an excellent pager for psql (also for general csvs).
- WorldMaker 3y agoSQL pretty printers have probably the widest variety of possible "pretty" options to support. I've seen so many disagreements over the years on how the right way to print SQL is. For instance, I've gotten huge fights by saying that I prefer "Sentence case" (example: `Select * from someTable where someId in (select otherId from otherTable)`; only "top-level" introductory keywords get a single capital letter to make them easier to scan for like you are reading prose, kind of, and no semicolons unless entirely required such as the termination of a Merge statement) versus how many people still seem to be telnetting their SQL in 2023 from terminals or punch cards that mandate shouting SQL keywords in all caps everywhere. (ETA: Being a big fan of Merge statements for a bunch of ETL trivia is partly how I got to "Sentence case". Merge statements are tough to read at the best of times and eliminating extraneous casing changes as noise by using more lower-case than not was a very useful thing to me. I don't need to highlight keywords versus everything else in a modern syntax highlighting bath, so casing becomes useful for way finding. A lower-case "select" is in the middle of something else.)
- tracker1 3y agoWith A formatter in place, I'm generally much happier, even if I don't always agree with the structure.