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!
Prefer strict tables in SQLite
81–90 of 188 posts
Re: Prefer strict tables in SQLite
#82Earlier 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’
Re: Prefer strict tables in SQLite
#83I'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!
Re: Prefer strict tables in SQLite
#84Coming 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…
Re: Prefer strict tables in SQLite
#85Earlier 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.
Re: Prefer strict tables in SQLite
#86Re: Prefer strict tables in SQLite
#87Earlier 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.”
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
#88Coming 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…
Re: Prefer strict tables in SQLite
#89Yeah 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…
Re: Prefer strict tables in SQLite
#90Earlier 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?