This is honestly more of a feature that exists because the SQL standard specifies it, and supporting it can be useful for people porting code from another DB th

This is honestly more of a feature that exists because the SQL standard specifies it, and supporting it can be useful for people porting code from another DB that uses a similar system. If you are not doing that, then it doesn't seem to provide enough value to be worth the headache of ading an additional preprocessor to your build chain. Not to mention, it likely messes with syntax highlighting, linters, etc. Indeed, this (or the equivalent in other languages) is one of the main ways the SQL standard expects to be used! It get presented before more familiar approaches, and various wording and placement choices make it clear that the standard considers this embedded SQL approach more core to how it works than other approaches. A design like libpq, ODBC, etc where the sql syntax needs to be parsed at runtime rather than compile time is considered "dynamic sql" by the standard, and the standard acts like it is less likely to be provided than this interface. Obviously that is hogwash. This is one of many reasons (like backwards compatibility) that unlike most other programming languages very few SQL implementations make much effort towards faithfully implementing the standard. PostgreSQL actually puts a lot more effort towards implementing the standard than many other popular RDBMses. Postgres has fairly few places where they intentionally violate the standard and don't hope to fix things in the future, and several are fairly obscure, or othewise not likely to cause issues. While Oracle has MANY super common features not spec complaint with no plans to fix. Same with SQL Server. I'm not sufficiently familiar with MySQL/MariaDB to evaluate how closely it tracks the SQL standard. It seems to claim only minor deviations, but that may well be from not claiming conformance at all with features it has implemented but differently from the standard.