Live data from Hacker News

Prefer strict tables in SQLite

evanhahn.com

81–90 of 188 posts

Re: Prefer strict tables in SQLite

#81
post #9

I'd like to see STRICT as the default. That's pretty much the only disagreement with the SQLite developer, who is an amazing guy that wrote an amazing tool!

Even foreign keys aren't enabled by default, you have to use `PRAGMA foreign_keys = ON;` [1]. The bigger issue with strict tables is that there is no equivalent pragma, and you're forced to use the non-standard STRICT on each CREATE TABLE. A global STRICT pragma was considered but not implemented, see this forum thread [2].

1. https://sqlite.org/foreignkeys.html

2. https://sqlite.org/forum/forumpost/1b9d073a37ca5998

Re: Prefer strict tables in SQLite

#82
post #15

Earlier quoted context omitted.

SQLite very rarely changes defaults because of their commitment to backwards compatibility. They don't want software written against SQLite 3.53 to start throwing errors when upgraded to 3.54 because suddenly `CREATE TABLE` is creating strict tables and the rest of the software breaks as a result.

The need ‘default sets’ so that as the very first command I can say ‘use 2026.1 defaults’

Or even better just SET STRICT_TABLES, or whatever other opt-in feature you want. A couple of such statements in the beginning of your migration script (refactored in a way to be reused across all migration scripts) and you are done. I wouldn't want to learn WTF "2026.1 defaults" are.

Re: Prefer strict tables in SQLite

#83
post #9

I'd like to see STRICT as the default. That's pretty much the only disagreement with the SQLite developer, who is an amazing guy that wrote an amazing tool!

Yes. I always considered that a downside of SQLite. You have to validate numeric fields on the read side or risk the application blowing up on bad data.

Re: Prefer strict tables in SQLite

#84
post #77

Coming from the enterprise SQL world, I never took SQLite seriously for the very reason that field types were not enforced by default. (Yes, I was agog when it became the backbone for app metadata on smartphones.) Anyway, reading this reminds me of the old chestnut from networking about choosing UDP over TCP for its low-latency and simplicity and then eventually adding nearly all the reliability facilities of TCP to…

> I never took SQLite seriously for the very reason that field types were not enforced by default. I can understand not taking it seriously if it was completely unsupported but I'm pretty sure most databases don't have perfect default configs. Even PostgreSQL needs configuration for optimal performance because the defaults are for low (minimum) spec systems. > then eventually adding nearly all the reliability facilit…

tuning defaults for performance feels much more acceptable than tuning defaults for correctness

Re: Prefer strict tables in SQLite

#85
post #53
post #50

Earlier quoted context omitted.

Well, I would also like a proper datetime/timestamp datatype that isn't just a string.

Someone should fork it in Rust using Claude and rename it SQRite. Strict type all the things.

https://github.com/tursodatabase/turso

Re: Prefer strict tables in SQLite

#87
post #36

Earlier quoted context omitted.

“I intended this to be an integer but it could really be anything” is not very useful.

Sure it is. If you encounter something that’s not an int, that could be a signal you have a bug in your writers. Or in the source of the data. That’s useful information compared to “oh, I have some ints and some strings, that’s ANY, everything is ok.”

> If you encounter something that’s not an int, that could be a signal you have a bug in your writers

Which, is something you could have caught before it got written at all if you had your db enforcing your types.

Re: Prefer strict tables in SQLite

#88
post #77

Coming from the enterprise SQL world, I never took SQLite seriously for the very reason that field types were not enforced by default. (Yes, I was agog when it became the backbone for app metadata on smartphones.) Anyway, reading this reminds me of the old chestnut from networking about choosing UDP over TCP for its low-latency and simplicity and then eventually adding nearly all the reliability facilities of TCP to…

> I never took SQLite seriously for the very reason that field types were not enforced by default. I can understand not taking it seriously if it was completely unsupported but I'm pretty sure most databases don't have perfect default configs. Even PostgreSQL needs configuration for optimal performance because the defaults are for low (minimum) spec systems. > then eventually adding nearly all the reliability facilit…

It wasn't option for the first 20 years of SQLite's existence.

Re: Prefer strict tables in SQLite

#89

Yeah my DB is the one place I want strict types. Well also RPCs. But SQLite is a somewhat different set of use cases, so maybe I'd understand https://sqlite.org/flextypegood.html more if I were using it. Like there's a point about random scripts not made for SQLite happening to work with it, which isn't normally a consideration for other DBMSes.

> Yeah my DB is the one place I want strict types. Well also RPCs. Which is why in most cases you are going to show at compile time that your code adheres to the typed structure. The SQLite schema you are developing alongside provides the type information for static analysis. There is no real benefit in also double checking again at runtime. Your code isn't going to magically mutate in a way that it starts inserting…

2004 called and they want their ignorant bad takes back

Re: Prefer strict tables in SQLite

#90
post #62

Earlier quoted context omitted.

Unless you don't know it exists of course

Is it better to learn that it exists through surprise , by way of an engine upgrade suddenly changing the behavior of the software you wrote while in the bliss of your ignorance?

Which is the worse surprise, when you update your dependency during development and get a fault, or when a user somehow ends up with a fault because of the previous default?
Post reply on HN