SQLite should have (Rust-style) editions • Hacker News Board

Re: SQLite should have (Rust-style) editions

#91

Post by IshKebab » Thu, Jul 16, 2026, 7:12 AM UTC

Polizeiposaune wrote: post #19

Rendello wrote: post #9

It might be worth bringing this up on the forum [1]. The developers are quite active there, and it's possible they've never considered this option, or they have considered it and have reasons to not go for it. The original design followed Postel's Law (see my comment from the other say [2]), it would (theoretically) be nice if that mess could be avoided by specifying an edition. Today I noticed I could do `pragma for…

The Postfix mailer has allowed recommended default behavior to evolve using its "compatibility_level" parameter: https://www.postfix.org/postconf.5.html#compatibility_level https://www.postfix.org/COMPATIBILITY_README.html You get a warning whenever you depend on the deprecated old default until you either move forward or specifically commit to the old behavior.

I think CMake actually has the best default evolution system out there (a bit surprising give how awful the actual language is).

Each "policy" they change can be manually set to old or new, and there's a global config to set them all at once based on the version of CMake.

https://cmake.org/cmake/help/latest/command/cmake_minimum_re...

Re: SQLite should have (Rust-style) editions

#92

Post by chuckadams » Thu, Jul 16, 2026, 7:32 AM UTC

Cyberdog wrote: post #68

GianFabien wrote: post #50

Nah, all those defaults are features . Of course, there are contexts where those defaults are unsuitable which means: Use a Different RDBMS!

Are there any other serverless SQL DBMSes?

Lots. Firebird and DuckDB come immediately to mind. Wikipedia lists several more, though not all of them are relational: https://en.wikipedia.org/wiki/Embedded_database

Re: SQLite should have (Rust-style) editions

#93

Post by spwa4 » Thu, Jul 16, 2026, 7:39 AM UTC

You know, 10 years ago one might have remarked ... changing these defaults means C programmers would have to correctly implement error handling and retries.

The reaction they're likely to have to that can probably be best described in megatons, like any other nuclear explosion ...

Re: SQLite should have (Rust-style) editions

#94

Post by andai » Thu, Jul 16, 2026, 7:42 AM UTC

postepowanieadm wrote: post #75

andai wrote: post #21

The "use strict" thing is interesting. I often hear people say, well we can't fix absurd behavior in JS because backwards compatibility! Well, we already did, and we can do it again!

"use strict;" is a perl thing. You also may turn experimental features on, or demand feature set from a certain version.

Brilliant. I have a similar idea for a language I've been envisioning.

So, my approach to dynamic features, global mutable state, etc... There's this big list of features which have caused me tremendous pain over the years. I am increasingly weary.

Sometimes you want or need them, though. You don't want the same level of strictness for every project (e.g. throwaway scripts or game jams), nor at every stage of a project -- e.g. being forced to specify invariants is something I'd love to be able to enable, but I wouldn't want that on while I'm still figuring out the basic structure of things.

So for game jams I'd put the language into #JAMMODE (which would be short for a bunch of other flags). But the point here is that jam mode should be opt-in, rather than opt-out. You should have to go out of your way to enable the footguns. And a file with #JAMMODE should be a little smelly. You should think, OK I'm actually shipping this thing now, let's get it out of #JAMMODE. (And strict files can't talk to jam files, and we probably want different strictness levels beyond Debug and Release, etc... someone told me with the strictness "zones" that I'm reinventing half of Ada, hahah.)

Re: SQLite should have (Rust-style) editions

#95

Post by bambax » Thu, Jul 16, 2026, 7:44 AM UTC

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation.

Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it.

I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that export to CSV. It's amazing how corrupt data can become: dates that are invalid, numbers that aren't numbers, strings strings strings everywhere.

Being able to store the data into tables that have types, but can accept anything, is simply great.

Re: SQLite should have (Rust-style) editions

#96

Post by andai » Thu, Jul 16, 2026, 7:44 AM UTC

crabmusket wrote: post #74

ShinyLeftPad wrote: post #26

Earlier quoted context omitted.

"use stricter"

"use strong" was a proposal from Google https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...

I became hopeful for a moment, then saw it's from 2015. Ouch! (Also, I love the name. I had a similar idea I called "use sane", but obviously that one wouldn't have gotten far...)

The strong typing thing is really interesting. After using JavaScript for a while, I developed PTSD around dynamic types. I became convinced that static typing was the only way to avoid hell.

Then I used Python for a while, and... experienced approximately none of my previous pain. I found that quite odd. Turns out what I was actually after was a sane type system, not a static one. In other words, strong types rather than weak ones.

I do think there are additional benefits to static typing, especially for larger projects and serious work. But I was surprised that most of the pain-delta was in this first jump:

Weak -> Strong -> Static

Re: SQLite should have (Rust-style) editions

#97

Post by platz » Thu, Jul 16, 2026, 7:49 AM UTC

sethev wrote: post #4

Interesting idea - I like seeing a list of pet-peeves followed by a proposal for a straightforward way to have a set of 'alternative defaults' that remains backwards compatible. If you don't want to opt in, don't run the new PRAGMA edition = 2026. Too often it's just a list of issues and a wish that everyone else will change. In (mild) defense of SQLITE_BUSY - busy_timeout just tells sqlite to sleep and retry up to t…

busy_timeout is often sidestepped (ignored) when a transaction attempts to upgrade from a read to a write producing SQLITE_BUSY.

By default, SQLite transactions start in DEFERRED mode, acting as read transactions until an actual write operation occurs.

If another connection begins writing to the database while your transaction is in this read state, an immediate SQLITE_BUSY error is triggered regardless of what you set busy_timeout to

Re: SQLite should have (Rust-style) editions

#98

Post by afiori » Thu, Jul 16, 2026, 7:52 AM UTC

groundzeros2015 wrote: post #33

sethev wrote: post #4

Interesting idea - I like seeing a list of pet-peeves followed by a proposal for a straightforward way to have a set of 'alternative defaults' that remains backwards compatible. If you don't want to opt in, don't run the new PRAGMA edition = 2026. Too often it's just a list of issues and a wish that everyone else will change. In (mild) defense of SQLITE_BUSY - busy_timeout just tells sqlite to sleep and retry up to t…

Yep. The whole locking database thing is this persistent myth about SQLite. All databases lock on write, it’s a question of the granularity of the lock. Multiple writers simply take turns.

yes but no... most database allow for at least as many parallel and concurrent writes as there are tables at a minimum.

The "lock on write" problem is that in MySQL i could run a OLAP pipeline for a few hours and have a fully functioning database with degraded perfomance, on SQLite the same pipeline would lock the database for the full hour. (there are surely ways to solve this (eg using the main db as read-only and a secondary db for writes or splitting the writes in incremental transaction), but it is not a "myth".

Re: SQLite should have (Rust-style) editions

#99

Post by poly2it » Thu, Jul 16, 2026, 7:53 AM UTC

bambax wrote: post #95

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…

> loose typing can be extremely useful

"Loose typing" enforced in a strict typing system can be useful in certain scenarios, but it is regrettable that it instead replaced the strict typing discipline for some time in software. Strict typing should be the default, because it is the most accurate description of data in the vast majority of cases.

Re: SQLite should have (Rust-style) editions

#100

Post by afiori » Thu, Jul 16, 2026, 7:55 AM UTC

appplication wrote: post #20

mort96 wrote: post #15

Earlier quoted context omitted.

Well you'd have the problem that an sqlite database file created on a Linux AMD64 box could be copied to an AArch64 macOS machine to be read there. And quite a lot of (cross platform) software build their file formats on top of SQLite.

I think my silly and unserious naive response would be linear scaling bundled binaries with number of platforms doesn’t seem to be that materially different in terms of total size. But I see your point, didn’t consider the architectures

it would be sorta enough to bundle the wasm binary