3 ms·

I wonder why they're not considering type modifiers, eg "TEXT" for dynamically-typed TEXT like now, and something like "STRICT TEXT" for erroring out when a non

I wonder why they're not considering type modifiers, eg "TEXT" for dynamically-typed TEXT like now, and something like "STRICT TEXT" for erroring out when a non-string is inserted. Or a "use strict" style pragma / parameter to sqlite3_open or sqlite3_exec, which errors out for that session (resp query) if something doesn't match the expected type.

mumblemumble 5y ago
My guess is that, given the nature of what SQLite is and the kinds of people who use it (IIRC, it was originally developed for military applications), they've also made a decision that mucking with such a core portion of the database's implementation has such a great potential for unseen consequences that it's just not worth the risk. A little bit like how, at least according to rumor, Python hasn't done anything about its famous global interpreter lock because, when they looked into it, they found that, while it would be a big performance boost in some areas, it would also cause a large performance degradation for the silent majority of people who aren't writing multithreaded Python code. It might be fun to fork it and try implementing a feature like this just to see, though. But I personally would rather see it happen as a (perhaps temporary) fork rather than a change to the core engine, so that people who are happy with SQLite's current type discipline don't have to be taken along for the ride.
- Zababa 5y ago
  > A little bit like how, at least according to rumor, Python hasn't done anything about its famous global interpreter lock because, when they looked into it, they found that, while it would be a big performance boost in some areas, it would also cause a large performance degradation for the silent majority of people who aren't writing multithreaded Python code. OCaml is going through something like that. It currently has a GIL, and they are working to remove it and allow multithreaded code. However, they're also constantly benchmarking single core performance because it's still the main use case, and they don't want too much regression.

mumblemumble 5y ago

My guess is that, given the nature of what SQLite is and the kinds of people who use it (IIRC, it was originally developed for military applications), they've also made a decision that mucking with such a core portion of the database's implementation has such a great potential for unseen consequences that it's just not worth the risk. A little bit like how, at least according to rumor, Python hasn't done anything about its famous global interpreter lock because, when they looked into it, they found that, while it would be a big performance boost in some areas, it would also cause a large performance degradation for the silent majority of people who aren't writing multithreaded Python code. It might be fun to fork it and try implementing a feature like this just to see, though. But I personally would rather see it happen as a (perhaps temporary) fork rather than a change to the core engine, so that people who are happy with SQLite's current type discipline don't have to be taken along for the ride.

Zababa 5y ago
> A little bit like how, at least according to rumor, Python hasn't done anything about its famous global interpreter lock because, when they looked into it, they found that, while it would be a big performance boost in some areas, it would also cause a large performance degradation for the silent majority of people who aren't writing multithreaded Python code. OCaml is going through something like that. It currently has a GIL, and they are working to remove it and allow multithreaded code. However, they're also constantly benchmarking single core performance because it's still the main use case, and they don't want too much regression.