Consider the latest trunk check-ins for SQLite, and the "Pre-release Snapshot" on the download page to be a beta for the upcoming 3.43.0 release of SQLite.

Please test the latest code and report any issues or concerns on this forum (either as a reply in this thread or as a separate thread) or directly to me at drh at sqlite dot org.

A summary of changes: https://sqlite.org/draft/releaselog/3_43_0.html.

Complete list of check-ins associated with the beta: https://sqlite.org/src/timeline?p=trunk&bt=release

The new function sqlite3_stmt_explain has not been added to the sqlite3_api_routines structure.

Thanks for that tip. The API has been added to that struct now.

The new SyncAccessHandle Pool WASM VFS is not mentioned in the release notes but is checked into the trunk so I assume it is to be released with 3.43. I think it is short-sighted to release it in its current state and I would strongly suggest either expending a little effort to allow a future upgrade or postpone its release until that can be done. Upgrading after release will otherwise be much more difficult.

Ideally it would be possible to copy SQLite database files to and from the browser file system the VFS uses for storage with only the file system API, a feature coined as filesystem transparency. That wasn't the case for original SAH Pool approach and the current SQLite implementation, but a modification of that approach would make it possible when the VFS is not active. This is a useful feature to have - for one thing it removes the need to write (and support) library code to import and export database files.

Unfortunately, this is not an upgrade that can be easily applied after release of the current trunk code. A copy-and-delete upgrade on databases that are larger than the remaining free space on the filesystem will be quite difficult even if possible at all.

It is possible, however, to tweak how metadata is stored so it would be possible to apply a future filesystem transparency upgrade without copy-and-delete. I estimate that this change would take about a day of developer effort.

Perhaps this future filesystem transparency upgrade will never happen, and that estimated one day of developer time and schedule delay would be wasted. That is a possibility, but one of the arguments in favor of that was that JSPI might solve everything, and I understand that path has been abandoned. Furthermore I just don't see how closing the door on this upgrade is worth saving a day or rushing a feature out that certainly wasn't in the original 3.43 planning.

The new SyncAccessHandle Pool WASM VFS is not mentioned in the release notes but is checked into the trunk so I assume it is to be released with 3.43.

It is part of 3.43 but the WASM additions have not historically been in the change log since their initial inclusion in 3.40. The /wasm site, in particular the news page, gets updated as things change in those parts.

I think it is short-sighted to release it in its current state and I would strongly suggest either expending a little effort to allow a future upgrade or postpone its release until that can be done. Upgrading after release will otherwise be much more difficult.

Realistically, there's not going to be any bandwidth for exploring the transparency support in any foreseeable future (certainly not this year), so i've shelved that as an eventuality for that VFS. If that changes, but it becomes too problematic to retrofit the new VFS, we have the option of creating a separate VFS for that feature.

I estimate that this change would take about a day of developer effort.

The trunk is currently in "pencil's down" mode, meaning only important bug fixes are permitted there until after the release. Even if the bandwidth were there to work on that feature, it's too late for the 3.43 release.

Perhaps ...time and schedule delay would be wasted.

Wouldn't be the first time ;).

That is a possibility, but one of the arguments in favor of that was that JSPI might solve everything, and I understand that path has been abandoned.

Unequivocally.

Furthermore I just don't see how closing the door on this upgrade is worth saving a day or rushing a feature out that certainly wasn't in the original 3.43 planning.

If it were just a matter of will, it would have been done before 3.43, but bandwidth constraints made it unrealistic :/.

The trunk is currently in "pencil's down" mode, meaning only important bug fixes are permitted there until after the release.

Perhaps the important bug fix would be to take it out.

Furthermore I just don't see how closing the door on this upgrade is worth saving a day or rushing a feature out that certainly wasn't in the original 3.43 planning.

If it were just a matter of will, it would have been done before 3.43, but bandwidth constraints made it unrealistic :/.

So defer the VFS until the next release. I imagine you could arrange for a day of bandwidth in the 3.44 schedule.

Perhaps the important bug fix would be to take it out.

If there are important functional issues, please point them out and we can certainly consider pulling it. Removing it for the lack of one nice-to-have feature would be overkill.

I imagine you could arrange for a day of bandwidth in the 3.44 schedule.

Development plans are always fluid, so it can't be ruled out, but i can't currently commit to anything less vague than that.

Removing it for the lack of one nice-to-have feature would be overkill.

It wouldn't be removing it for the lack of a feature. It would be removing it because it unnecessarily chokes off an upgrade path for anyone who uses it. It would be not releasing something in a dead end state to developers.

I can't upgrade my own VFS because it's in the same dead end state. You still have an opportunity not to do that.

I can't upgrade my own VFS because it's in the same dead end state. You still have an opportunity not to do that.

Fair point, and i do truly appreciate the sentiment and feedback, but i don't feel that either implementation is in a dead-end state now, in the sense of not being useful as-is. Adding file name transparency would make it easier to get stuff into and out of, but its lack is not a show-stopper.

FWIW, what you're describing as scientific notation is called engineering notation on Wikipedia. The form returned by decimal_sci is called normalised scientific notation or standard form.

What I was taught way back when in my math classes in Belgium as "wetenschappelijk notatie" (i.e. scientific notation) was the normalised form as well.

Schools/universities in Canada are the same way. Might be primarily/only a British thing to flip the two names

Since there is some confusion about what "scientific notation" means, I have changed the name of the function to "decimal_exp()" with corresponding adjustments to the documentation. There is no need to cling to a potentially confusing name, since the code is unreleased and we do not have backwards compatibility concerns.

I'm very happy with this solution. I would also be happy with the possible future introduction of 'decimal_eng()' to describe the 'thousands' exponential notation I described. This neatly sideskips any ambiguity of what 'scientific notation' means.

We have started running the release checklist for version 3.43.0. The release will occur once the checklist goes all-green.