0
via You must be vouched for by a vouched user to participate.
-
Let's scratch that itch!
In
src/build.c:1046the parser checks the validity of an object (table, index, view or trigger). Ifwritable_schema=ONit skips the error checks in theCREATE TABLEstatement. Dangerous but convenient. If the schema is corrupt, these checks wouldn't catch it.Oh cool! Thanks for digging in. It's always interesting to me how many "accidental features" there are lurking in code where every behavior isn't necessarily defined. In this case though, it was an explicit choice which is awesome.
On a side note, what an interesting formatting style. I don't read a ton of C, but choices on what brackets/parens require spaces and what ones don't seem almost opposite to what I'm used to. Easy enough to read still though.
I want everything typed but I'm not a polemic. Sqlite has chosen to be a raw bytes database with some metadata and checks on top to help you type those bytes if you want. Application logic can have control over the data's type validity. Adding types to sqlite3 is just another layer of logic that might even duplicate effort.
That's a nice way of looking at it...but I'd argue that if the intent is to be a "bag of bytes" you don't want to imply it's anything but that. Simultaneously if you want it to be typed, it seems less than ideal to have them front and center and then be wishy-washy with them.
I'm not a polemic, but I believe compromise on things like this corrupts conceptual clarity. Choosing one or the other would help learners quite a bit I'd think. I understand engineering tradeoffs are the enemy of such thoughts though.
sqlite3 is older than the current type system usage trends. There were strongly typed languages back then, but it was for niche/research uses. People wrote in C. That's why it provides those little helpers and it's not absolute about types. I bet if it was written with say, Ocaml it would be strongly typed from the get go.
Oh totally. It started as a Tcl extension, and Tcl is famously loose with it's types...all data types can be treated as strings. I assume that's where that came from.
Hipp based semantics off an early version of Postgres, so there was a deliberate choice to loosen the type guarantees from what Postgres offered.
This is awesome! The loose type system is my main complaint about sqlite...I know it's a matter of opinion, but it always struck me as a really strange choice. I just like being confronted with errors as fast as humanly possible.
I wish there was some way to check how much code directly interfacing with sqlite before this was effectively asserts on the structure of what's returned.
All that being said, the arguments for the loose type system are linked from that article https://www.sqlite.org/flextypegood.html . They don't particularly move me, and their points seem to be ones that would more effectively be addressed in other ways. But again, I understand it's more of a project choice than something objectively good or bad.
Also, fun quote:
Currently working up the motivation to understand that quirk. Just kind of sounds like a fun random happenstance.