Since _time_format=sqlite was introduced in
064df839 it has used (as described in that commit message):

> the time package format "2006-01-02 15:04:05.999999999-07:00".
> This is the format mattn/go-sqlite3 uses and is format 4 at
> https://sqlite.org/lang_datefunc.html#time_values.

A couple months later this parameter was documented in
8e27ffc8 as corresponding
to format 7 which is not and has never been the case
(format 7 has a T between the date and the time).

fix(docs): _time_format=sqlite corresponds to format 4

See merge request cznic/sqlite!91

- Enable configurable vtab options and add MATCH coverage. Expose Context.Config alongside EnableConstraintSupport, wire sqlite3_vtab_config through vtab create/connect, and document the new hook. Add a unit test ensuring MATCH constraints work when enabled.

Thanks HaoZi!

If a COMMIT fails (e.g. with SQLITE_BUSY), SQLite may leave the transaction
open, but database/sql expects the driver.Tx to be finished and the
underlying connection to be clean when Commit() returns.

This mismatch caused connection pool poisoning, where subsequent uses of
the connection would fail with "cannot start a transaction within a transaction".

This fix checks sqlite3_get_autocommit after a failed Commit. If the
transaction is still active, it forces a ROLLBACK to reset the connection
state, while still returning the original error to the caller.

Fixes https://github.com/modernc-org/sqlite/issues/2

Add sqlite-vec support

See merge request !93

See CHANGELOG.md for more information

_timezone accepts an IANA timezone name, such as
"UTC", and applies it to both reads and writes.

For writes, time.Time values are converted to the
target timezone before formatting.

For reads, timezone-less strings are interpreted
as being in the target timezone.

Supporting configuration at the DB driver level
helps avoid industrial accidents when working with
SQLite datetime strings, which lack time zones.

So that time.Times may be formatted identically to how SQLite
does it natively with datetime and CURRENT_TIMESTAMP.

add _timezone DSN query parameter

See merge request cznic/sqlite!94

add _time_format=datetime support

See merge request !95

This particular loop occurs a lot.
Give it a name and make it concise.
No functional changes.
The goal is to make upcoming changes a bit clearer.

The multi-statement path was subject to both double-frees and leaks.

Having allocs declared once and re-used across loop iterations
made it hard to manage correctly. Reduce its scope to within the
inner closure and defer freeAllocs there.

Even within a loop, it was easy to mismanage; force callers to deal
with this consistently by passing a pointer to newRows and zeroing there.

Take care to Close rows objects from previous iterations when
a subsequent statement in a multi-statement query fails.

The tests here demonstrate both double-frees and
leaked memory without these changes.

I noticed while in this code that in the optimized
single-statement path, there are some unnecessary calls to
reset/clearBindings after newRows. When newRows fails, its internal
defer calls r.Close, which finalizes the prepared statement.
The subsequent reset and clearBindings calls would then operate
on an already-finalized handle. This would be bad, except that
columnCount/columnName cannot fail on a valid pstmt.
Therefore, the error path is dead code.
I didn't touch it, even though pedantically it looks wrong.
There might also be some dangling SQLITE_STATIC references.
Again, this appears to be safe in practice, so I left it alone.
A follow-up could make it conform to the docs
and ensure extra safety.

I don't plan to do any of this follow-up work;
I am focused for now only on demonstrable, directly testable issues.

improve memory safety of allocs in stmt.query

See merge request !96