71–80 of 186 posts
Oh hi, author here. Fun to see this make it to HN.
Found what appears to be a minor mistake you may want to fix: "This means that a dangling reference easily results in a reference to the wrong column " should probably be "... a reference to the wrong row ". (In the paragraph about SQLite's tendency to re-use ROWIDs).
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.
The "use strict" thing is interesting. I often hear people say, well we can't fix absurd behavior in JS because backwards compatibility! Well, we already did, and we can do it again!
"use stricter"
https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...
The "use strict" thing is interesting. I often hear people say, well we can't fix absurd behavior in JS because backwards compatibility! Well, we already did, and we can do it again!
The "use strict" thing is interesting. I often hear people say, well we can't fix absurd behavior in JS because backwards compatibility! Well, we already did, and we can do it again!
"use strict;" is a perl thing. You also may turn experimental features on, or demand feature set from a certain version.
SQLite gets so much praise here but when you start using it, you realize quickly how bad it is, the type system is by default very limited and dangerous. It's like comparing old php with a strongly typed language. There is not even a date type...
SQLite is slightly different from Rust in that it is a data container. It’s somewhat more common for people to move SQLite database files from one machine to another and then inspect using the command line tool. And it is often the case that the embedded SQLite version in your app is a newer version than whatever version /usr/bin/sqlite3 happens to be. Adding editions to your SQLite file will probably break this use…
It seems SQLite could be evolve to solve this by just bundling itself entirely in the data files? After all, the binary is less than 1MB, anywhere you’re putting a database surely has at least that much overhead, for most applications it’s less than a drop in the bucket. I’d be interested to learn if there are any db implementations that take this approach, or reasons this wouldn’t work.
And a lot of users of sqlite statically link sqlite within their executable, they actually recommend that instead of dynamically linking.
[0] https://sqlite.org/vfs.html ctrl-f for 'append'
Edit: I got confused between the sqlar command and the append vfs so fixed it.
Earlier quoted context omitted.
The "3" refers to the file format (or rather, represents a breaking file format change vs 2), which the devs have committed to keep backward-compatible until 2050. https://sqlite.org/lts.html
It also refers to what the binary on my PATH is called, also what the library name I need to pass to link against it. They even had an sqlite4: https://sqlite.org/src4/doc/trunk/www/design.wiki