cargo-semver-checks VS ddl-diff

If you'd like to dig deeper, here are some links:

- cargo-semver-checks: https://github.com/obi1kenobi/cargo-semver-checks

- Trustfall query engine, which powers cargo-semver-checks: https://github.com/obi1kenobi/trustfall

- Trustfall playground, where you can query Rust library APIs in your browser -- for example, "which structs in `itertools` are importable by more than one path": https://play.predr.ag/rustdoc#?f=2&q=*3-Structs-importable-f...

- 10min conference talk on Trustfall: https://www.hytradboi.com/2022/how-to-query-almost-everythin...

I'm also giving a talk at P99 CONF in a few months about how Trustfall's new optimizations API made cargo-semver-checks over 2300x faster: https://twitter.com/PredragGruevski/status/16893002495908003...

I strongly recommend that anybody creating new error types for public APIs read Study of std::io::Error by u/matklad to see some ways that error types can [need to] be future-proofed. I don't know if cargo-semver-checks can catch these issues when they're generated by a macro, but it'd be something people using this crate should carefully look into.

cargo-semver-checks will implement a check for cases like this, and many other hazards like it. The check will be major, or minor, or just a hazard — whatever the overall community decides is right.

Full release notes: https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.18.0

Release notes, TL;DR: Rust 1.65+ only, no more false positives due to moved+re-exported items.

So, after digging about in the docs, I found the Best Practices[0] page which lays out what you describe. I was disappointed to find it is just using idempotent creation statements for procedures and views and putting them all in files that are re-run on each migration step-along with each new roll forward migration-so that new versions of these logic objects replace any old ones. This is not exactly something that liquidbase provides, should be easily replicatable, and I was hoping it'd do diffs to provide similar experience on tables as well.

After some web searching, I came across a project[1] that's trying to do what I describe but it appears to be dead. I'm surprised that migration tools (that I looked through) don't already support such a basic approach that I suspect I'm missing something obvious. Some fundamental block in how SQL works or maybe it doesn't work that well in practice for, in concept, it sounds easy to script using what they call a shadow db and `pg_diff`.

[0]: https://docs.liquibase.com/concepts/bestpractices.html

[1]: https://github.com/cbowdon/ddl-diff