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

61–70 of 186 posts

Re: SQLite should have (Rust-style) editions

#61

Post by tptacek »

doc_ick wrote: post #40
tptacek wrote: post #5

Earlier quoted context omitted.

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.

I’d say these are reasonable settings for most uses. Though do you know of surveys that back this up? I don’t mean to nit pick too much, I’d just like to see common uses and the data.

SQLite is used in a lot of unconventional settings (for SQL databases) where these settings don't make as much sense. But that's what makes the "edition" useful; it captures the use case we all mean when we're thinking of the "database" lego in an application stack.

Re: SQLite should have (Rust-style) editions

#62

Post by nullsanity »

doc_ick wrote: post #40
tptacek wrote: post #5

Earlier quoted context omitted.

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.

I’d say these are reasonable settings for most uses. Though do you know of surveys that back this up? I don’t mean to nit pick too much, I’d just like to see common uses and the data.

[dead]

Re: SQLite should have (Rust-style) editions

#65

Post by hmry »

tmpfile wrote: post #63

Why not a .conf file like everything in /etc or postgresql.conf?

These proposed editions are per connection.

A system-wide config file in /etc that changes defaults for every program would break any program that assumes the old defaults.

It also wouldn't solve the problem of having to manually find out what the current recommended defaults are. With editions, you can simply enable the latest one and know you've got the right defaults.

Re: SQLite should have (Rust-style) editions

#66

Post by mikepurvis »

tptacek wrote: post #61
doc_ick wrote: post #40

Earlier quoted context omitted.

I’d say these are reasonable settings for most uses. Though do you know of surveys that back this up? I don’t mean to nit pick too much, I’d just like to see common uses and the data.

SQLite is used in a lot of unconventional settings (for SQL databases) where these settings don't make as much sense. But that's what makes the "edition" useful; it captures the use case we all mean when we're thinking of the "database" lego in an application stack.

While that's true, editions are more about leaving legacy decisions behind while keeping the backward compatibility promise.

Even if you're in one of those unconventional settings (say, a bare-metal microcontroller or something), you'd probably still start from edition 2026 and mutate your settings accordingly, rather than using the defaults that are 26 years old.

Re: SQLite should have (Rust-style) editions

#67

Post by Animats »

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.

> It's reasonable to suggest that the alternative settings for each of these suggestions is probably the wrong default for 2026.

That's the key concept here. When tightening up the defaults, an "edition" mechanism is a good solution.

Now we need this for C/C++, which have much legacy stuff which ought to go away for new code. This is more feasible than it used to be, because "Convert this Edition 4 code to Edition 5" is something LLMs can do now.

I'd never seen all the rules for SQLite soft typing written out before. Those are more complicated than strong typing.

Re: SQLite should have (Rust-style) editions

#69

Post by Cyberdog »

eduction wrote: post #53

HN… for the love of god… please please stop trying to make SQLite be something it isn’t. Leave this poor project alone. It’s a great tool if you want to give a local app its own database. If you need concurrent writes and full ACID guarantees of an industrial strength database, use an industrial strength database. Yes, other databases will require you to read more manual pages and configure a service. Higher up front…

I don’t understand why a local app database shouldn’t still have the same basic functionality and data guarantees as the full-sized ones.

Re: SQLite should have (Rust-style) editions

#70

Post by eduction »

yomismoaqui wrote: post #59
eduction wrote: post #53

HN… for the love of god… please please stop trying to make SQLite be something it isn’t. Leave this poor project alone. It’s a great tool if you want to give a local app its own database. If you need concurrent writes and full ACID guarantees of an industrial strength database, use an industrial strength database. Yes, other databases will require you to read more manual pages and configure a service. Higher up front…

Just by its testing and its number of installations (real world testing) you could consider SQLite being more "industrial strength" than any other DB on the market. - https://sqlite.org/testing.html - https://sqlite.org/mostdeployed.html EDIT: added links

Exactly. There is no reason to complain about it. It is successful. People who find it lacking can use something else, there are many options.
Post reply on HN