Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite should have (Rust-style) editions

mort.coffee

Post reply on HN
Print view View original

41–50 of 186 posts

Re: SQLite should have (Rust-style) editions

#41

Post by pstuart »

tptacek wrote: post #5
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…

This isn't so much a list of pet peeves as it is the almost universal way people that work seriously with SQLite configure the database. It's reasonable to suggest that the alternative settings for each of these suggestions is probably the wrong default for 2026.

You are probably correct, but I imagine the SQLite team's dedication to backwards compatibility has things the way they are so that existing systems can user later versions a swap without worrying about changing the SQL using it.

Re: SQLite should have (Rust-style) editions

#43

Post by rmunn »

mort96 wrote: post #2

Oh hi, author here. Fun to see this make it to HN.

Found what appears to be a minor mistake you may want to fix: "This means that a dangling reference easily results in a reference to the wrong column" should probably be "... a reference to the wrong row". (In the paragraph about SQLite's tendency to re-use ROWIDs).

Re: SQLite should have (Rust-style) editions

#44

Post by rmunn »

ShinyLeftPad wrote: post #26
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 stricter"

"use loose; footloose; kick off your Sunday shoes"

Re: SQLite should have (Rust-style) editions

#45

Post by Retr0id »

andrewchambers wrote: post #42

It is sqlite3. Emphasis on the 3 - it already has 'editions'.

The "3" refers to the file format (or rather, represents a breaking file format change vs 2), which the devs have committed to keep backward-compatible until 2050. https://sqlite.org/lts.html

Re: SQLite should have (Rust-style) editions

#47

Post by mamcx »

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…

After read, it hit me that because sqlite is a DB, "editions" as-is not work.

Because it not tied to the data but to the code.

Instead, what I think should be is that the PRAGMAs become "data" that is always checked in full with "if manually set" and then on next "open" THEY GET APPLIED.

That is.

(and in the command line when open interactively they show up).

Re: SQLite should have (Rust-style) editions

#48

Post by andrewchambers »

Retr0id wrote: post #45
andrewchambers wrote: post #42

It is sqlite3. Emphasis on the 3 - it already has 'editions'.

The "3" refers to the file format (or rather, represents a breaking file format change vs 2), which the devs have committed to keep backward-compatible until 2050. https://sqlite.org/lts.html

It also refers to what the binary on my PATH is called, also what the library name I need to pass to link against it.

They even had an sqlite4:

https://sqlite.org/src4/doc/trunk/www/design.wiki

Post reply on HN