For what it's worth, SQLite works just fine for some blockchains without Rust extensions, e.g. nimbus-eth2[+] uses SQLite with `journal_mode = WAL` to locally persist Beacon Chain data.
Other Beacon Chain client implementations (there are several in wide use) may use SQLite, or something else, I'm not sure at the moment.
This is great to see. We've been using UDFs with SQLite and .NET for about 3 years now.
With just a little bit of imagination, you can build a very powerful domain-specific language on top of a SQL dialect. There is nothing that says your new SQL functions have to be free from side effects either.
You can also do some crazy stuff with recursive SQL evaluation. I.e. a UDF that executes raw SQL command text, which itself can contain the same invocation. Bonus points if this command text resides in the same database and can reflect/edit itself at runtime...
1. I can just write functions in whatever programming language I want.
2. Not having to worry as much about overwriting other UDFs, since different connections can have the same UDF with a different implementation.
3. Having the DB (SQLite) and the function definitions in the same application code and in the same process makes some things a lot easier and flexible.
> You can also do some crazy stuff with recursive SQL evaluation. I.e. a UDF that executes raw SQL command text, which itself can contain the same invocation. Bonus points if this command text resides in the same database and can reflect/edit itself at runtime...
This is super intriguing, would love to see more details / examples of this.
https://news.ycombinator.com/item?id=32725455