The incredible Janet for Mortals book by Ian Henry was my first exposure to peg. It's very interesting and changed my thinking on programming in a big way. It's a free book.

https://janet.guide/pegular-expressions/

There is nothing wrong with using PEGs for SQL parsing, but this article (I didn't read the paper) presents flawed arguments:

- tech $X is from the 60s, therefore it is bad and/or outdated: one doesn't need to "disrupt" or innovate in everything to become modern. There are plenty of things from the 60s that still don't have a better replacement, and its OK to keep using it.

- "YACC-style parsers" clumps together parsers that are generated at compile-time, from declarative grammars, using LALR(1). But that's not inherit to the technique or algorithm: a parser can be LALR(1) from a declarative grammar and still extensible at run-time, or provide LL(1) alongside, or be built from statements instead of a grammar. There's nothing wrong with using PEGs over "YACC-style" parsers, but not for these distorted reasons.

From a practical standpoint, for anyone who needs to parse SQL today, I can recommend datafusion's sqlparser-rs. This is what we use in http://sql-page.com , and I regularly contribute to it. I don't know anything else that matches its level of support for all the crazy little-known syntax particularities of the various SQL dialects.

In particular, Microsoft SQL Server seems to do everything just a little bit differently, and sqlparser-rs does support its idiosyncrasies most of the time.

> parsers should be rewritten using modern abstractions like Parser Expression Grammars (PEG), which allow dynamic changes to the accepted query syntax and better error recovery.

The DuckDb project continues to impress me every day.