I might be missing something—is there a reason why rewriting it in Rust would be a prerequisite to adding these features, vs just starting a fork?

And in this case the project intends to be fully compatible, so they wouldn't be able to unilaterally adopt or drop features anyway.

Agreed! Rewriting in Rust (or any other language) is not required for those features. A fork and modifying the existing C code could also result in those features (and I might do just that if it doesn't come around soon).

An SQLite fork will have a hard time being compelling enough to draw users away from the main project. Being written in Rust is the most compelling reason that I could think of. SQLite has many annoying quirks (foreign key constraints disabled by default and non-strongly-typed columns are my two pain points) but a fork that addresses them would still not pull me away from the original project that I have so much trust in.

If I were to fork SQLite, drawing users away from the main project would be a non-goal. The goal would be to get strict tables and foreign key constraints enforced 100% of the time.

Yeah, I would assume that any project like this would strive to be a soft fork that just has a few minimal patches to address specific needs, not something that actually tries to compete with the original.

Agreed! If I were to fork sqlite, that would be my aim.

If that was the case, they wouldn't introduce cross incompatibilities in the changes they made (or would at least discuss compatibility in the docs), and they'd make any added features useful to others by properly documenting them.

Compatibility for libSQL is a one way street. I don't expect Limbo to be any different.

They did add support for strict type checking fairly recently, and you can turn on foreign key checking I think.

Here is the STRICT table type page: https://www.sqlite.org/stricttables.html It is fairly straightforward: you just have to add STRICT to your table definition and you have it.

And the FOREIGN KEY support is here: https://www.sqlite.org/foreignkeys.html The two requirements are that your build not have it disabled, and that you execute `PRAGMA foreign_keys = ON;` when you open the database (every time you open the database).

I don't view opt-in as a very good defaults for these.

Then build with SQLITE_DEFAULT_FOREIGN_KEYS=1 to make it opt-out (and to opt-out you'd need to inject SQL).

As for STRICT: if you make your tables STRICT, there's no opt-out.

So why is this an issue? Do you want them to break the file format to say "from this version forward, all tables are STRICT"? What does that really buy you?

It's an embed database: anyone who can mess with your database and circumvert integrity can also open the file and corrupt it.

> What does that really buy you

It removes a footgun for new users. That's not an insignificant benefit.

Probably not worth the backwards compatibility cost, but it definitely is an issue.

My builds of SQLite do enable foreign keys by default.

This is easy to do for any project using the amalgamation.