Hacker News new | ask | show | jobs
by dolmen 12 days ago
Counterpoint: each new edition will add bloat to SQLite as future edition will need to keep each past edition pragma set for backward compatibility.

As SQLite is often used embedded, bloat matters.

So I suggest that "PRAGMA edition" to be only be a shortcut to a list of PRAGMA commands, that would be expanded at the library level: PRAGMA edition would never appear in the DB file. As such, the build of the library would just support a limited set of editions, with a removal policy in default builds. Maybe editions could even be defined at runtime (a system table?) as a way to load them dynamically if old editions are needed beyond builtin support (think about the state of SQLite in 2046).

2 comments

It's always really funny to me when commenters don't read the article and then phrase the article's point like they invented it.
Isn’t that exactly what the author suggests? Editions as a set of config options that are already there.

The config options are already implemented, so the heavy lifting is done. Editions would amount to a few hundred bytes.

That's certainly not the case for making STRICT tables the default.

But figuring that out requires understanding how they are implemented, or reading the forum, which the author admittedly didn't do.

The rest are assumptions about best practices (also not shared by the developers of SQLite).