We add an explicit "buildtime_bindgen" to the "session" feature, rather
than just relying on the transitive "session" -> "preupdate_hook" ->
"buildtime_bindgen", to proof against possible future changes.
This just using them in patterns without a catchall. I left things alone
that seem very unlikely to change (`Value`, `ValueRef`, `DatabaseName`,
etc...). This might help reduce the number of breaking changes we need
(rusqlite is still pre-1.0 so it doesn't really matter that much, but
breaking changes complicate the story around when we can cut releases).
This is essentially to get a release out that contains `in_gecko` so
that this library can be used in firefox.
Note: This had temporarially been 0.18.0, but as noted in
https://github.com/jgallagher/rusqlite/pull/619#discussion_r370435032
there isn't an actual need for this, as it isn't a breaking change.
By releasing it as 0.17.2, we can still link rusqlite 0.21 against it,
which lets us avoid needing to cut a release of rusqlite just for a
gecko-specific linkage flag (I imagine there are a few more rusqlite
features we'd want for the next release).
Cargo itself changes the PATH.
So `libsqlite3-sys` is always rebuilt on Windows platform.
To avoid this, we ignore PATH change.
If the PATH has been modified in such a way that a different SQLite library is found,
you will have to also modify SQLITE3_LIB_DIR to make cargo rebuild `libsqlite3-sys`
Fix#435.
We've been hitting the default `MAX_VARIABLE_NUMBER` and
`MAX_EXPR_DEPTH` with quite basic tests here in Prisma. I was able to
run the tests by using the Arch Linux packaged libsqlite3, but when
turning on the bundled version I was able to get my test to crash with
this test project:
https://github.com/pimeys/sqlite_parameter_test
Now taking a look how Arch Linux builds sqlite, I was able to find two
flags fixing the issue:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/sqlite#n35
I think it would be safe to include them in rusqlite.
