This is an automated email from the ASF dual-hosted git repository.
zeroshade pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/arrow-go.git
The following commit(s) were added to refs/heads/main by this push:
new 67ef40b0 chore: Bump modernc.org/sqlite from 1.57.0 to 1.58.0 (#1295)
67ef40b0 is described below
commit 67ef40b0e11a2696a4f10c05ec09a6429815c4f2
Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
AuthorDate: Tue Sep 8 12:22:29 2026 -0400
chore: Bump modernc.org/sqlite from 1.57.0 to 1.58.0 (#1295)
Bumps [modernc.org/sqlite](https://gitlab.com/cznic/sqlite) from 1.57.0
to 1.58.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://gitlab.com/cznic/sqlite/blob/master/CHANGELOG.md";>modernc.org/sqlite's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>Entries for v1.38.1 through v1.44.1 and for v1.49.1 were added on
2026-09-05, reconstructed from the git history and the merge requests
they cite; they were missing at release time.</p>
<ul>
<li>
<p>2026-09-05 v1.59.0:</p>
<ul>
<li>Hand user-defined function and aggregate callbacks a pooled
<code>*FunctionContext</code> instead of allocating a fresh one per
call. After the <code>[]driver.Value</code> pooling of <a
href="https://gitlab.com/cznic/sqlite/-/work_items/226";>#226</a> this
was the last driver-side heap allocation per invocation: one 16-byte
object for every <code>Scalar</code>, <code>Step</code>,
<code>WindowInverse</code>, <code>WindowValue</code> and
<code>Final</code> call. The context now also carries the invocation's
<code>sqlite3_context</code>, so accessor methods can be added to it
later without touching the trampolines. Like the argument slice, it is
valid only for the duration of the callback and must not be retained
past its return; the documentation on <code>FunctionContext</code> and
on the callbacks now says so. On the 1000-row, 3-argument noop scalar
UDF benchmark this removes a further 1000 allocs/op (5756 to 4756, and
3756 to 2756 with <code>VolatileArgs</code>) and 16 KB/op; on the
reporter's reproducer from <a
href="https://gitlab.com/cznic/sqlite/-/work_items/226";>#226</a> it
removes about 12% of the remaining allocations (25.3M to 22.4M
allocs/op, 553 MB to 505 MB per iteration).</li>
<li>Updates [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/226";>#226</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/226";>https://gitlab.com/cznic/sqlite/-/issues/226</a>).
See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/137";>#137</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/137";>https://gitlab.com/cznic/sqlite/-/merge_requests/137</a>).</li>
</ul>
</li>
<li>
<p>2026-09-01 v1.58.0:</p>
<ul>
<li>Upgrade to <a
href="https://sqlite.org/releaselog/3_53_4.html";>SQLite 3.53.4</a>.
Upstream's own fix for the journal-rollback data-corruption bug is part
of this release, so the local super-journal patch v1.56.0 introduced —
and promised to drop once upstream shipped theirs — is dropped; recovery
behavior is unchanged. This also bumps the pinned
<code>modernc.org/libc</code> to v1.75.6; as always, downstream modules
must pin the exact <code>modernc.org/libc</code> version this module's
<code>go.mod</code> pins (see [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/177";>#177</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/177";>https://gitlab.com/cznic/sqlite/-/issues/177</a>)).</li>
<li>Add opt-in support for <strong>Linux Open File Description (OFD)
locks</strong> on database files. A POSIX record lock is owned by the
(process, inode) pair, so the kernel drops every lock the process holds
on a database file whenever any descriptor of that file is closed: an
<code>os.Open</code>/<code>Close</code> for a hash, a backup check or a
metadata probe anywhere in the process — third-party libraries included
— silently strips SQLite's transaction locks and leaves the file
unprotected against other processes. With OFD locking enabled, the locks
belong to the open file description that placed them and survive such a
close. <strong>Off by default, and staying off until the mode has
real-world mileage</strong>: without opting in, locking behavior is
byte-for-byte that of previous releases. Enable it by setting
<code>MODERNC_SQLITE_OFD_LOCK=1</code> in the environment the process
starts with (any value but the empty string or one starting with
<code>0</code>; read once, at library initialization), or from Go with
the new <code>OFDLocking(true)</code>, which overrides the variable and
must run before the first connection is opened;
<code>OFDLockingEnabled</code> reports the mode in effect. The switch is
deliberately <strong>process-wide rather than a DSN parameter</strong>:
POSIX and OFD locks taken by one process are different owners to the
kernel and genuinely conflict, so every connection to a database file
inside one process must use the same kind, and a per-DSN knob would
advertise a granularity the kernel does not offer (see the discussion in
<a href="https://gitlab.com/cznic/sqlite/-/work_items/255";>#255</a>).
Because the two kinds do not release one another, the mode is frozen at
the process's first lock attempt: later attempts to change it return the
new <code>ErrOFDLockingTooLate</code>, while querying, and setting the
value already in effect, keep working. On kernels older than 3.15, and
on filesystems that reject OFD locks, the first lock attempt falls back
to POSIX locks for good and <code>OFDLocking</code> returns the new
<code>ErrOFDLockingUnavailable</code> from then on, which is also how
<code>OFDLockingEnabled</code> turning false reports the fallback; the
same error is returned on every platform but Linux, where the API exists
but OFD locks do not. Two boundaries to note: the immunity covers the
locks on the database file itself, while WAL's <code>-shm</code>
coordination stays on POSIX locks; and code in the same process that
takes fcntl record locks of its own on a database file — which used to
never conflict with SQLite's, while quietly destroying them — now
conflicts with them loudly instead. The C side —
<code>F_OFD_SETLK</code> routing through a designated per-inode locking
descriptor that preserves upstream's <code>unixInodeInfo</code>
semantics (last-unlocker release, PENDING piggybacking,
<code>unix-excl</code>), guarded to <code>__linux__</code> — ships in
the transpiled sources via <a
href="https://gitlab.com/cznic/libsqlite3/-/merge_requests/3";>libsqlite3!3</a>
and its follow-up hardening, with the OFD lock constants from <a
href="https://gitlab.com/cznic/libc/-/merge_requests/33";>libc!33</a>;
the review rounds, the <code>/proc/locks</code> measurements behind the
design, and the Tcl lock/WAL gate that runs both modes are recorded in
[GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/255";>#255</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/255";>https://gitlab.com/cznic/sqlite/-/issues/255</a>)
and those merge requests.</li>
<li>Add the accompanying regression tests. The four OFD scenarios
contributed in merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/136";>#136</a> — lock
survival across a rogue <code>os.Close</code>, the interleaved-readers
lock lifecycle, the read-only-first designated-descriptor migration, and
the failed-first-lock cleanup — run in a re-executed child process with
<code>MODERNC_SQLITE_OFD_LOCK=1</code>, since the mode is process-wide
and frozen at the first lock so the suite's own process cannot switch; a
positive control asserts the variable really switched the mode on before
each scenario runs, and the two scenarios whose invariants hold under
both modes also run in the parent process's inherited mode.
<code>TestOFDLockingSetter</code> exercises the Go call path end to end
in a clean child — off by default, enabled before the first connection,
the kernel-visible <code>OFDLCK</code> record in
<code>/proc/locks</code> as the positive control, frozen after the first
lock — and on every other platform the switch is asserted to report
itself unavailable.</li>
<li>Resolves [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/255";>#255</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/255";>https://gitlab.com/cznic/sqlite/-/issues/255</a>).
See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/136";>#136</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/136";>https://gitlab.com/cznic/sqlite/-/merge_requests/136</a>),
thanks Nathan Herring (<a
href="https://gitlab.com/technosloth";><code>@technosloth</code></a>),
and thanks Gani Georgiev (<a
href="https://gitlab.com/ganigeorgiev";><code>@ganigeorgiev</code></a>)
for pressing the opt-in default!</li>
</ul>
</li>
<li>
<p>2026-08-19 v1.57.0:</p>
<ul>
<li>Add an opt-in <code>_defensive</code> DSN query parameter that turns
on SQLite's defensive mode for the connection, disabling the SQL-level
features that let ordinary statements deliberately corrupt the database
file. When <code>_defensive=1</code> (or any
<code>strconv.ParseBool</code> true value) is supplied, the driver calls
<code>sqlite3_db_config</code> with
<code>SQLITE_DBCONFIG_DEFENSIVE</code> immediately after
<code>sqlite3_open_v2</code> and before every other parameter is
applied, so the PRAGMAs the driver itself runs, the <code>_pragma</code>
list, and every statement the caller prepares are all subject to it. On
such a connection <code>PRAGMA writable_schema=ON</code>, <code>PRAGMA
journal_mode=OFF</code> and <code>PRAGMA schema_version=N</code> become
silent no-ops, and writes to a virtual table's shadow tables (fts5's
<code>_data</code>, <code>_idx</code> and so on) and to
<code>sqlite_dbpage</code> fail with "table ... may not be
modified"; reading those tables, ordinary use of the virtual tables
that own them, and <code>VACUUM</code> are unaffected. The flag has no
PRAGMA equivalent, so <code>sqlite3_db_config</code> — and therefore a
DSN parameter — is the only way to reach it short of dropping to
<code>modernc.org/sqlite/lib</code>. The value is parsed before
<code>sqlite3_open_v2</code>, so an invalid one fails the connection
without creating the database file, and the parameter must appear at
most once: a repeated <code>_defensive</code> is an error rather than
letting the first value silently win. Absence of the parameter, or
<code>_defensive=0</code>, leaves SQLite's default behavior unchanged;
existing DSNs continue to work byte-for-byte. Two limits are worth
stating plainly, since the name invites more confidence than the flag
earns. Defensive mode is a hardening measure, not a sandbox for hostile
database files: it is one of several steps <a
href="https://www.sqlite.org/security.html";>SQLite recommends</a> for
that purpose, and this build compiles with neither
<code>SQLITE_TRUSTED_SCHEMA=0</code> nor <code>SQLITE_DQS=0</code> and
exposes no authorizer. And it is a property of the connection, not of
the database file — a second handle opened on the same file without the
parameter is unrestricted.</li>
<li>Reject the one DSN combination defensive mode would otherwise
swallow in silence. <code>_defensive=1</code> together with
<code>_journal_mode=OFF</code> (or <code>_journal=OFF</code>) now fails
the connection instead of opening one in which neither parameter was
honoured: SQLite turns <code>PRAGMA journal_mode=OFF</code> into a no-op
that still reports success, so the driver would have accepted the mode,
executed it, and left the journal untouched without telling anyone. The
check runs in the validation phase introduced in v1.55.0, before any
statement executes, so a rejected DSN cannot leave the database
half-configured. <code>_pragma</code> remains the exception it has
always been: <code>_pragma=journal_mode(OFF)</code> alongside
<code>_defensive=1</code> still runs and is still silently ignored by
SQLite. Only DSNs using <code>_defensive</code> can be affected, and
that parameter is new, so no DSN that opened before changes
behavior.</li>
<li>See [GitHub pull request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/6";>#6</a>](<a
href="https://redirect.github.com/modernc-org/sqlite/pull/6";>modernc-org/sqlite#6</a>),
thanks wsman!</li>
<li>Ship the sqlite-vec license notice this module has been missing.
<code>modernc.org/sqlite/vec</code> has bundled the transpiled <a
href="https://github.com/asg017/sqlite-vec";>sqlite-vec</a> sources since
v1.47.0, but the module carried only its own BSD-3-Clause
<code>LICENSE</code> and the public-domain SQLite notice. sqlite-vec is
Copyright (c) 2024 Alex Garcia, dual-licensed Apache-2.0 OR MIT and used
here under MIT, whose terms require the copyright and permission notice
to accompany substantial portions of the software — which 2.8 MB of
transpiled <code>vec/</code> plainly is. The notice now ships as
<code>LICENSE-SQLITE_VEC</code> in the module root, byte-identical to
the <code>LICENSE-MIT</code> in the upstream v0.1.9 archive and named
after the file <code>modernc.org/libsqlite_vec</code> extracts it into.
Attribution was never absent — <code>vec</code>'s package documentation
has named the extension, pinned the version and linked upstream — but
the license text itself was, and the omission was ours:
<code>vendor_libs/main.go</code> copied the per-target transpiles and
nothing else. It now copies the notice alongside them and fails the
vendoring run if it cannot, so a <code>make vendor</code> can no longer
quietly drop it. The <code>vec</code> package documentation gained a
License section recording that the package is under a different license
from the rest of this module.</li>
<li><strong>The SQLite notice is renamed from
<code>SQLITE-LICENSE</code> to <code>LICENSE-SQLITE</code></strong>;
update any direct links to it. Its contents are unchanged and SQLite
remains public domain. The name now matches both the new
<code>LICENSE-SQLITE_VEC</code> beside it and the
<code>LICENSE-<upstream></code> convention every other modernc.org
repository follows, but it is more than cosmetic: <code>go mod
vendor</code> selects the files it copies into a downstream
<code>vendor/</code> tree by matching each name against a fixed list of
prefixes — <code>LICENSE</code> among them — so a name merely
<em>ending</em> in <code>LICENSE</code> was never propagated. Both
bundled notices now travel with the code into vendored builds, which is
where the MIT terms on <code>vec/</code> keep applying. No code changes;
no behavior changes.</li>
<li>Let a caller-constructed <code>Driver</code> register its own
functions, collations and virtual table modules. <code>Driver</code> has
always held four categories of registration state, but only
<code>RegisterConnectionHook</code> could put anything on a constructed
one: functions and collations were reachable through the package-level
API alone, and modules through the package-level driver only, which left
the <code>modules</code> field written and read through that instance
and so process-global state wearing a per-instance field.
<code>Driver</code> now has <code>RegisterFunction</code>,
<code>RegisterScalarFunction</code>,
<code>RegisterDeterministicScalarFunction</code>,
<code>RegisterCollationUtf8</code> and <code>RegisterModule</code>, plus
<code>Must*</code> variants of the first four, each registering on that
<code>Driver</code> alone; the methods are safe to call concurrently,
and the zero <code>Driver</code> is ready to use as-is.
<code>vtab.RegisterModule</code> also honours its <code>db</code>
argument now: a non-nil <code>db</code> registers on the driver backing
it when that driver implements the new
<code>vtab.ModuleRegisterer</code>, while a nil <code>db</code> keeps
targeting the driver this package registers as <code>sqlite</code>. One
existing pattern changes behavior, narrowly and loudly:
<code>vtab.RegisterModule(db, ...)</code> where <code>db</code> was
opened on a caller-constructed <code>Driver</code> used to discard the
<code>db</code> argument and land on the <code>sqlite</code> driver,
reaching every connection in the process; it now lands on the
constructed driver alone, so a <code>sql.Open("sqlite")</code>
connection that used to resolve such a module gets <code>no such
module</code> instead. The same pattern is also the one way an existing
program could hold one module name on both a constructed
<code>Driver</code> and the package-level one: there the first of the
two registrations used to win and the second was refused as already
registered, whereas now the package-level implementation wins on the
constructed <code>Driver</code>'s connections regardless of the order
they ran in. Reaching that case at all means the program ignored an
error the older version returned. Two smaller deviations round out the
list: <code>Driver.RegisterModule</code> reports no error for such a
collision, and <code>vtab.RegisterModule</code> now validates its name
and module arguments before the not-implemented check, so a call with an
empty name that returned <code>vtab: RegisterModule not wired into
engine</code> outside this driver returns <code>vtab: module name must
be non-empty</code> instead. Everything else is additive against
v1.56.0: the package-level registration functions target the same driver
they always did, connections still receive every module registered
through the package-level path whichever <code>Driver</code> opened
them, and a <code>db</code> opened on the <code>sqlite</code> driver
resolves to that same driver. The isolating change discussed in [GitLab
issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/254";>#254</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/254";>https://gitlab.com/cznic/sqlite/-/issues/254</a>)
is deliberately not made here.</li>
<li>See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/135";>#135</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/135";>https://gitlab.com/cznic/sqlite/-/merge_requests/135</a>),
thanks Ian Chechin!</li>
<li>Promote <code>freebsd/386</code>, <code>freebsd/arm</code> and
<code>netbsd/amd64</code> to fully supported platforms. All three are
now listed in the package documentation's platform table, which had
carried seventeen entries while this module shipped, cross-built and
tested twenty. They arrived as <strong>experimental</strong> in v1.53.0
— <code>netbsd/amd64</code> reviving a port that had been broken for
years, <code>freebsd/386</code> replacing a stale, effectively untested
SQLite 3.41 transpile, and <code>freebsd/arm</code> entirely new — and
were deliberately kept out of that table until they had accumulated
real-world exposure, with promotion promised once "a period of
broader real-world testing … elapses without surprises". That
period has elapsed: all three have been in the builder test matrix and
in <code>make build_all_targets</code> since v1.53.0, all three pass the
full test suite on this release's commit alongside the seventeen
platforms already listed, and no open issue reports a defect in any of
them. The two <code>netbsd/amd64</code> build failures filed before the
revival, [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/202";>#202</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/202";>https://gitlab.com/cznic/sqlite/-/issues/202</a>)
and [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/234";>#234</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/234";>https://gitlab.com/cznic/sqlite/-/issues/234</a>),
no longer reproduce at this commit: <code>Xsqlite3_is_interrupted</code>
is present in the sources that target selects, and the
<code>mu.enter</code>/<code>mu.leave</code> symbols that broke the build
are gone. Documentation only — the transpiled sources under
<code>lib/</code> are byte-for-byte what v1.56.0 shipped, and nothing
about how these targets behave changes.</li>
</ul>
</li>
<li>
<p>2026-08-03 v1.56.0:</p>
<ul>
<li>Re-vendor the transpiled SQLite sources, picking up
<code>modernc.org/libsqlite3</code>'s fix for an upstream
<strong>data-corruption bug in SQLite 3.53.3's journal
rollback</strong>. The SQLite version is unchanged at <a
href="https://sqlite.org/releaselog/3_53_3.html";>3.53.3</a>; what
changes is that the amalgamation is now patched before it is transpiled.
3.53.3 reworked <code>readSuperJournal()</code> to return the
super-journal name through a <code>char**</code> out-parameter, and
<code>pager_playback()</code> now tests that pointer where it used to
test <code>zSuper[0]</code>. A crash during the commit of a
multi-database (ATTACH) transaction can leave the super-journal name and
its checksum zeroed while the name length and the trailing magic
survive; the checksum is a plain byte sum, so an all-zero name still
validates and <code>readSuperJournal()</code> hands back a non-NULL
pointer to an empty string. <code>pager_playback()</code> then calls
<code>sqlite3OsAccess(pVfs, "", SQLITE_ACCESS_EXISTS)</code>,
gets ENOENT, and deletes the hot journal without playing it back —
leaving the database corrupted. This is not a transpilation artifact: a
plain gcc build of the stock 3.53.3 amalgamation fails on the same bytes
while 3.53.2 recovers them, and it is what has been making upstream's
own <code>test/crash.test</code> fail intermittently, in roughly 2% of
runs, on every platform. The patch restores the pre-3.53.3 behaviour of
reporting a <code>(nul)</code> super-journal name and will be dropped
once upstream ships its own fix. Every supported target carries it.</li>
<li>Two targets change beyond that patch. On <code>linux/s390x</code>
the regenerated transpile allocates C bit-fields MSB-first, as the
big-endian platform ABI requires, rather than LSB-first; this comes from
<code>modernc.org/cc/v4</code> v4.29.1 and touches bit-field accesses
throughout the SQLite core, s390x being this module's only big-endian
target. On <code>linux/riscv64</code> the transpile was regenerated on a
host running GCC 11.4.0 where the previous one used GCC 13.3.0, which
drops a handful of unexported compiler-predefined macro constants (the
<code>__FLT16_*</code> family, <code>__DBL_IS_IEC_60559__</code> and
friends) and changes the <code>COMPILER=gcc-13.3.0</code> entry
<code>PRAGMA compile_options</code> reports to
<code>COMPILER=gcc-11.4.0</code>; no SQLite code generation differs.
Every other target's generated code is byte-identical to v1.55.0 apart
from the journal-rollback patch above.</li>
<li>Bump the pinned <code>modernc.org/libc</code> to v1.74.4, and the
remaining dependencies to their current releases. v1.74.2 and v1.74.3
are retracted upstream — a <code>freeaddrinfo</code> lock leak that
deadlocks name resolution — and v1.74.4 is the fix. As always,
downstream modules must pin the exact <code>modernc.org/libc</code>
version this module's <code>go.mod</code> pins (see [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/177";>#177</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/177";>https://gitlab.com/cznic/sqlite/-/issues/177</a>)).</li>
<li>Documentation sweep. <code>openbsd/amd64</code> and
<code>openbsd/arm64</code> join the supported platforms table in the
package documentation: both have been in the builder test matrix since
January and are cross-built by <code>make build_all_targets</code>, but
had never been listed. The <code>vfs</code> DSN query parameter — which
names a VFS registered with SQLite, such as one returned by
<code>vfs.New</code> — is now documented alongside the other DSN
parameters on <code>Driver.Open</code>. The "Debug and development
versions" section no longer describes a <code>GO_GENERATE</code>
environment variable and a <code>go generate</code> that this repository
has not had since <code>generator.go</code> moved to
<code>modernc.org/libsqlite3</code>; it now points at that repository
and <code>make vendor</code> instead, and the stale
<code>//go:generate</code> directive naming the removed file is dropped
with it. <code>modernc.org/sqlite/vec</code> and
<code>modernc.org/sqlite/vfs</code> gained the package doc comments they
were missing, so both finally carry a synopsis on pkg.go.dev.
Documentation only; no behavior changes.</li>
<li>Add <code>NewConnector</code>, returning a
<code>database/sql/driver.Connector</code> for use with
<code>sql.OpenDB</code>. It opens the same connections
<code>sql.Open("sqlite", dsn)</code> does, from the same
registered driver, so every function, collation, connection hook and
virtual table module registered through this package applies to them. It
exists for callers that need to interpose on the physical connections
<code>database/sql</code> opens — tracing, metrics, connection-scoped
setup — which <code>sql.Open</code> gives no access to: such a caller
can embed the returned <code>Connector</code>, override
<code>Connect</code>, and pass its own wrapper to
<code>sql.OpenDB</code>. Previously the only way to reach the registered
driver was the <code>db, _ := sql.Open("sqlite",
""); drv := db.Driver(); db.Close()</code> idiom, which works
only because <code>sql.Open</code> does not connect and this driver does
not implement <code>driver.DriverContext</code>; and the only way to get
a wrapper into a <code>*sql.DB</code> was <code>sql.Register</code>,
which is process-global, panics on a name it has already seen, and
cannot be undone, so a library had to invent a unique driver name per
configuration. <code>sql.OpenDB</code> registers nothing. Constructing a
<code>&sqlite.Driver{}</code> is not an alternative — its fields are
unexported, so it carries none of the registrations.
<code>NewConnector</code> checks the DSN only as far as it can without
opening a database — a query string that does not parse, and conflicting
<code>vfs</code> parameters; everything else continues to be validated
when the connection is opened, so an unknown parameter or an
out-of-range value is reported by <code>Connect</code> rather than at
construction. Nothing about the existing <code>sql.Open</code> path
changes: <code>*Driver</code> deliberately still does not implement
<code>driver.DriverContext</code>, so <code>sql.Open</code> remains lazy
and DSN errors continue to surface where they always have. A runnable
sample is in <code>examples/connector</code>. Resolves [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/253";>#253</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/253";>https://gitlab.com/cznic/sqlite/-/issues/253</a>),
thanks Alessandro Segala (<a
href="https://gitlab.com/ItalyPaleAle";><code>@ItalyPaleAle</code></a>)!</li>
<li>Document that a caller-constructed <code>sqlite.Driver</code> is not
the driver this package registers as <code>"sqlite"</code>.
Its fields are unexported, so it starts with no functions, collations or
connection hooks and the only way to give it any is its own
<code>RegisterConnectionHook</code> method; the package-level
<code>Register*</code> functions always apply to the registered driver.
Connections such a <code>Driver</code> opens therefore run without the
package-level functions and collations — and because a registered
function silently replaces a SQLite built-in of the same name, a
<code>Driver</code> you construct can evaluate <code>upper(x)</code>,
<code>date(x)</code> and the like differently from one opened through
<code>sql.Open</code>. Virtual table modules are the one exception: they
are held process-globally and reach every <code>Driver</code>.
Constructing one remains supported for the private-hook pattern — a
driver registered under a name of its own with <code>sql.Register</code>
so its connection hooks apply only to its own connections — and is
otherwise best avoided in favour of <code>sql.Open</code> or
<code>NewConnector</code>. Documentation only; no behavior changes.</li>
</ul>
</li>
<li>
<p>2026-07-20 v1.55.0:</p>
<ul>
<li>Add <code>github.com/mattn/go-sqlite3</code>-compatible shorthand
DSN query parameters to ease migration from that driver:
<code>_busy_timeout</code>/<code>_timeout</code>,
<code>_foreign_keys</code>/<code>_fk</code>,
<code>_journal_mode</code>/<code>_journal</code>,
<code>_synchronous</code>/<code>_sync</code>,
<code>_auto_vacuum</code>/<code>_vacuum</code>, and
<code>_query_only</code>, each setting the correspondingly named PRAGMA.
Values are validated against the same set <code>mattn/go-sqlite3</code>
accepts (case-insensitive) and an unrecognized value fails the
connection with an error, so a typo such as
<code>_synchronous=fu1l</code> or <code>_foreign_keys=yes_please</code>
is reported rather than silently downgrading durability or dropping
foreign-key enforcement. The keys are applied in a fixed order
independent of their order in the DSN — <code>_busy_timeout</code> and
<code>_auto_vacuum</code> before any <code>_pragma</code> values
(<code>auto_vacuum</code> must be set before the database is first
written), the rest after, and <code>_query_only</code> last — and where
a key and its alias are both supplied the alias wins, matching
<code>mattn/go-sqlite3</code>; selection is by presence rather than by
value, so supplying the alias empty
(<code>_foreign_keys=on&_fk=</code>) suppresses the PRAGMA rather
than deferring to the primary key, again matching that driver. Behavior
change to note: prior releases ignored these keys entirely, so a DSN
carried over from a <code>mattn/go-sqlite3</code> setup changes in two
ways. A recognized key that previously did nothing now takes effect —
<code>_foreign_keys=on</code> begins enforcing constraints against data
that may already violate them, <code>_journal_mode=wal</code>
persistently converts the database file, and <code>_query_only=1</code>
makes the connection read-only. And a value outside the accepted set now
fails the connection with an error where the same DSN previously opened
successfully — for example a duration-style
<code>_busy_timeout=5s</code> or <code>_timeout=5000ms</code>, neither
of which is the integer that key requires. Review such DSNs before
upgrading. <code>_pragma</code> is unchanged and no pre-existing
parameter changes meaning, though see the following entry for a change
in when all of them are validated.</li>
<li>See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/134";>#134</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/134";>https://gitlab.com/cznic/sqlite/-/merge_requests/134</a>),
thanks Toni Spets (<a
href="https://gitlab.com/beeper-hifi";><code>@beeper-hifi</code></a>)
and Ian Chechin!</li>
<li>Validate every DSN query parameter before applying any of them.
Parameters were previously checked as each was reached, so a DSN whose
later parameter was rejected had already executed the PRAGMAs ahead of
it. Because <code>PRAGMA journal_mode</code> and <code>PRAGMA
auto_vacuum</code> are persistent changes to the database file, a DSN
such as <code>file:x.db?_journal_mode=wal&_synchronous=bogus</code>
failed the connection and yet left <code>x.db</code> converted to WAL. A
failed <code>Open</code> now leaves the database as it found it. This
covers the pre-existing <code>_txlock</code>, <code>_timezone</code>,
<code>_time_format</code>, <code>_time_integer_format</code>,
<code>_inttotime</code> and <code>_texttotime</code> parameters as well
as the shorthand keys above: all of them were validated only after the
<code>_pragma</code> list had already run, so the same DSN shape — a
valid <code>_pragma=journal_mode=wal</code> alongside a misspelled
<code>_txlock</code> — converted the file before reporting the error.
Only the values accepted for each parameter are unchanged; a DSN that
opened successfully before still opens, and one that failed still fails
with the same error. <code>_pragma</code> remains the sole exception,
since its values are executed verbatim and cannot be checked in advance:
a malformed <code>_pragma</code> is still rejected by SQLite as it runs,
after any earlier <code>_pragma</code> in the list has taken
effect.</li>
</ul>
</li>
<li>
<p>2026-07-15 v1.54.0:</p>
<ul>
<li>Upgrade to <a
href="https://sqlite.org/releaselog/3_53_3.html";>SQLite 3.53.3</a>. This
also bumps the pinned <code>modernc.org/libc</code> to v1.74.1; as
always, downstream modules must pin the exact same
<code>modernc.org/libc</code> version this module's <code>go.mod</code>
pins (see [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/177";>#177</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/177";>https://gitlab.com/cznic/sqlite/-/issues/177</a>)).</li>
<li>Under the opt-in <code>_texttotime</code> DSN parameter, best-effort
parse date-shaped TEXT values from columns SQLite reports with an empty
declared type — aggregates and expressions over a date column
(<code>MAX(d)</code>, <code>COALESCE(d, ...)</code>,
<code>upper(d)</code>, <code>d || ''</code>), subqueries, and typeless
real columns (<code>CREATE TABLE t(x)</code>) — into
<code>time.Time</code>, instead of delivering them as a raw string that
<code>Scan</code> cannot store into a <code>*time.Time</code>. The
existing declared
<code>DATE</code>/<code>DATETIME</code>/<code>TIME</code>/<code>TIMESTAMP</code>
path is unchanged; this only adds the empty-decltype case. The
conversion is strictly best-effort: a value that does not parse as a
time falls through to the original string, so no <code>Scan</code> that
worked before can newly fail. <code>ColumnTypeScanType</code> continues
to report <code>string</code> for empty-decltype columns, since the
declared type cannot prove the column is temporal. Without
<code>_texttotime</code> the behavior is byte-for-byte unchanged.
Resolves [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/248";>#248</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/248";>https://gitlab.com/cznic/sqlite/-/issues/248</a>).</li>
<li>See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/133";>#133</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/133";>https://gitlab.com/cznic/sqlite/-/merge_requests/133</a>),
thanks Ian Chechin!</li>
</ul>
</li>
<li>
<p>2026-06-21 v1.53.0:</p>
<ul>
<li>Add <strong>experimental</strong> <code>netbsd/amd64</code> support,
resolving the long-standing build break in [GitLab issue <a
href="https://gitlab.com/cznic/sqlite/-/work_items/246";>#246</a>](<a
href="https://gitlab.com/cznic/sqlite/-/issues/246";>https://gitlab.com/cznic/sqlite/-/issues/246</a>).
This target is intentionally <strong>not yet listed among the supported
platforms</strong> in the package documentation: the port had been
broken for years and is only now revived, and there is as yet no
real-world experience running it under production workloads. Green CI is
not the same as battle-tested — so while the full test suite (including
the <code>pcache</code> and <code>vec</code> packages and the
<code>-race</code> concurrency test) passes on NetBSD 10.1 / Go 1.26.3,
and the entire upstream toolchain (<code>libc</code>, <code>cc</code>,
<code>ccgo</code>, <code>libz</code>, <code>libtcl8.6</code>,
<code>libsqlite3</code>, <code>libsqlite_vec</code>) is green on the
NetBSD CI builder, the target is offered for evaluation only. If you run
NetBSD, please exercise it with your own workloads and report back via
<a href="https://gitlab.com/cznic/sqlite/-/work_items/246";>#246</a>; the
intent is to promote it to a fully supported platform after a period of
broader real-world testing (on the order of a month) elapses without
surprises.</li>
<li>Implementation notes: the previously shipped
<code>lib/sqlite_netbsd_amd64.go</code> was a stale old-generator
transpile that no longer compiled (the
<code>mu.enter</code>/<code>mu.leave</code> break in <a
href="https://gitlab.com/cznic/sqlite/-/work_items/246";>#246</a>); it is
replaced by a fresh new-generator transpile consistent with every other
platform, and <code>modernc.org/sqlite/vec</code> (sqlite-vec) is
vendored and auto-registers on netbsd. Correct operation requires the
matching pinned <code>modernc.org/libc</code>, which carries two
NetBSD-specific fixes found during this work: the <code>mmap(2)</code>
<code>PAD</code>-argument ABI (without it, concurrent WAL access faults
with SIGBUS in the WAL-index shared memory) and a working
<code>abort(3)</code> (the prior stub left SQLite's crash-recovery
<code>writecrash</code> test unable to terminate by signal). As usual,
downstream modules must pin the exact <code>modernc.org/libc</code>
version this module's <code>go.mod</code> pins.</li>
<li>See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/82";>#82</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/82";>https://gitlab.com/cznic/sqlite/-/merge_requests/82</a>),
thanks Leonardo Taccari (<a
href="https://gitlab.com/iamleot";><code>@iamleot</code></a>) and Thomas
Klausner (@<em>wiz</em>)!</li>
<li>Add <strong>experimental</strong> <code>freebsd/386</code> and
<code>freebsd/arm</code> support. As with the <code>netbsd/amd64</code>
target above, these two 32-bit FreeBSD ports are intentionally
<strong>not yet listed among the supported platforms</strong> in the
package documentation: <code>freebsd/386</code> previously shipped a
stale, effectively untested SQLite 3.41 transpile, and
<code>freebsd/arm</code> is entirely new, so neither has real-world
production mileage yet. Both are now freshly transpiled at SQLite 3.53.2
consistent with every other platform, build cleanly, and pass the full
test suite (core, WAL/concurrency, and the <code>vec</code> package) on
the FreeBSD CI builders; they are offered for evaluation only. If you
run 32-bit FreeBSD, please exercise these targets with your own
workloads and report back — the intent is to promote
<code>freebsd/386</code>, <code>freebsd/arm</code>, and
<code>netbsd/amd64</code> to fully supported platforms in a future
release cycle, once a period of broader real-world testing elapses
without surprises.</li>
<li>Implementation notes: correct operation on <code>freebsd/arm</code>
requires the matching pinned <code>modernc.org/libc</code> (v1.73.4),
which fixes the per-arch <code>mmap(2)</code> <code>off_t</code>
encoding for 32-bit FreeBSD; without it the WAL shared-memory mapping
faults with SIGBUS under concurrent access, the same class of bug found
on the netbsd port. As usual, downstream modules must pin the exact
<code>modernc.org/libc</code> version this module's <code>go.mod</code>
pins.</li>
<li>See [GitLab merge request <a
href="https://gitlab.com/cznic/sqlite/-/work_items/119";>#119</a>](<a
href="https://gitlab.com/cznic/sqlite/-/merge_requests/119";>https://gitlab.com/cznic/sqlite/-/merge_requests/119</a>),
thanks Olivier Cochard-Labbé (<a
href="https://gitlab.com/ocochard";><code>@ocochard</code></a>)!</li>
<li>Add a Go-facing wrapper for <code>SQLITE_CONFIG_PCACHE2</code>.
<code>PageCache</code> is the factory and <code>Cache</code> the
per-database instance, both idiomatic Go interfaces; <code>Page</code>
exposes the raw <code>Buf</code> and <code>Extra</code> pointers that
SQLite reads through the C pcache contract.
<code>RegisterPageCache</code> and <code>MustRegisterPageCache</code>
install the module process-globally before the first
<code>sql.Open</code>; subsequent Open calls are gated through a
one-shot <code>Xsqlite3_config(SQLITE_CONFIG_PCACHE2)</code> so a
too-late Register returns <code>ErrPageCacheTooLate</code> rather than
silently falling through to the built-in pcache1. The binding owns the
<code>sqlite3_pcache_page</code> stub and re-consults the implementation
on every Fetch, reusing the stub only when the returned
<code>Page</code> value is unchanged, which keeps a bounded/evicting
purgeable cache safe by construction.</li>
</ul>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/722282f38b49191a4e24569eeac960bc033bd8f0";><code>722282f</code></a>
CHANGELOG.md: document the OFD locking opt-in and the SQLite 3.53.4
upgrade</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/5dcac5fbafc8194fd069f61ede3c7efbd482a2ff";><code>5dcac5f</code></a>
sqlite: add the opt-in OFDLocking switch to Linux OFD locks</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/51d267714fcb4ebb2ca0969c3d31815c18fd82fb";><code>51d2677</code></a>
Merge branch 'ofd-lock-test'</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/3f99e260f63ff2de76a94976e3d976ee75a8a4d1";><code>3f99e26</code></a>
update dependencies, make vendor</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/9159fa5ff00bd00f72e6893b71682b3348fa853d";><code>9159fa5</code></a>
test: add Linux OFD lock regression tests</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/2acd716d384a147b8daf1d91507f6346d409deff";><code>2acd716</code></a>
test: add Linux OFD lock persistence test across os.Close</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/bd9dcb65646988cc78aa56effa9a69fd04893478";><code>bd9dcb6</code></a>
add Readme Headline...</li>
<li><a
href="https://gitlab.com/cznic/sqlite/commit/93f0742ee384d5dbba5e6cd7d49afd0e9604160c";><code>93f0742</code></a>
add Readme Headline</li>
<li>See full diff in <a
href="https://gitlab.com/cznic/sqlite/compare/v1.57.0...v1.58.0";>compare
view</a></li>
</ul>
</details>
<br />
<details>
<summary>Most Recent Ignore Conditions Applied to This Pull
Request</summary>
| Dependency Name | Ignore Conditions |
| --- | --- |
| modernc.org/sqlite | [>= 1.34.a, < 1.35] |
</details>
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot]
<49699333+dependabot[bot]@users.noreply.github.com>
---
go.mod | 6 +++---
go.sum | 24 ++++++++++++------------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/go.mod b/go.mod
index 5cf4d56b..9a5d2eef 100644
--- a/go.mod
+++ b/go.mod
@@ -51,7 +51,7 @@ require (
gonum.org/v1/gonum v0.17.0
google.golang.org/grpc v1.83.2
google.golang.org/protobuf v1.36.12
- modernc.org/sqlite v1.57.0
+ modernc.org/sqlite v1.58.0
)
require (
@@ -94,7 +94,7 @@ require (
golang.org/x/text v0.41.0 // indirect
golang.org/x/tools v0.48.0 // indirect
google.golang.org/genproto/googleapis/rpc
v0.0.0-20260526163538-3dc84a4a5aaa // indirect
- modernc.org/libc v1.74.4 // indirect
+ modernc.org/libc v1.75.6 // indirect
modernc.org/mathutil v1.7.1 // indirect
- modernc.org/memory v1.11.0 // indirect
+ modernc.org/memory v1.12.1 // indirect
)
diff --git a/go.sum b/go.sum
index e41254b0..c0bb4b6d 100644
--- a/go.sum
+++ b/go.sum
@@ -249,30 +249,30 @@ gopkg.in/yaml.v2 v2.2.4/go.mod
h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod
h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b/go.mod
h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
-modernc.org/cc/v4 v4.29.1 h1:MKgdCV3WykTSPqpVrnxdEDS0HEd2FHpKZDzxzU5LyeI=
-modernc.org/cc/v4 v4.29.1/go.mod
h1:OnovgIhbbMXMu1aISnJ0wvVD1KnW+cAUJkIrAWh+kVI=
-modernc.org/ccgo/v4 v4.34.6 h1:sBgfIwyN0TQ9C5hwIeuqyeAKyMWnbvj2fvpF4L11uzU=
-modernc.org/ccgo/v4 v4.34.6/go.mod
h1:SZ8YcN9NG7XVsQYdm6jYBvi8PQP1qi+kqB6OhjqI3Fk=
+modernc.org/cc/v4 v4.29.2 h1:h6+9ciCnPKutf4I03CvheAvDLX7+IHlqR6Iy6J+cgd8=
+modernc.org/cc/v4 v4.29.2/go.mod
h1:OnovgIhbbMXMu1aISnJ0wvVD1KnW+cAUJkIrAWh+kVI=
+modernc.org/ccgo/v4 v4.35.0 h1:F+TUsmw09QxLzmi3aeYYGxjAXarmZaKgj3mKQHNaA8w=
+modernc.org/ccgo/v4 v4.35.0/go.mod
h1:qrVGs9S3Sr2Ztcg9ve+kTAYMp5a3YvWjo+SoN06kJ5I=
modernc.org/fileutil v1.4.0 h1:j6ZzNTftVS054gi281TyLjHPp6CPHr2KCxEXjEbD6SM=
modernc.org/fileutil v1.4.0/go.mod
h1:EqdKFDxiByqxLk8ozOxObDSfcVOv/54xDs/DUHdvCUU=
modernc.org/gc/v2 v2.6.5 h1:nyqdV8q46KvTpZlsw66kWqwXRHdjIlJOhG6kxiV/9xI=
modernc.org/gc/v2 v2.6.5/go.mod h1:YgIahr1ypgfe7chRuJi2gD7DBQiKSLMPgBQe9oIiito=
-modernc.org/gc/v3 v3.1.4 h1:2g65LGVSmFQrXeITAw97x7hCRvZFcyE1uDP+7Vng7JI=
-modernc.org/gc/v3 v3.1.4/go.mod h1:HFK/6AGESC7Ex+EZJhJ2Gni6cTaYpSMmU/cT9RmlfYY=
+modernc.org/gc/v3 v3.1.5 h1:21ldfPfRYE31Tb7B3mwAK8gy1AxP4+dKjrOQPfqakoc=
+modernc.org/gc/v3 v3.1.5/go.mod h1:HFK/6AGESC7Ex+EZJhJ2Gni6cTaYpSMmU/cT9RmlfYY=
modernc.org/goabi0 v0.2.0 h1:HvEowk7LxcPd0eq6mVOAEMai46V+i7Jrj13t4AzuNks=
modernc.org/goabi0 v0.2.0/go.mod
h1:CEFRnnJhKvWT1c1JTI3Avm+tgOWbkOu5oPA8eH8LnMI=
-modernc.org/libc v1.74.4 h1:fX1Omw4o2/1C2iRkkIsrQTasJQldLhRmuPreXLoWs9k=
-modernc.org/libc v1.74.4/go.mod h1:eeQAS9W3sZeKYMFubydxJpII9ybHWshk+7or7bLG9co=
+modernc.org/libc v1.75.6 h1:yKk8qo+Di4gkmvRboK8ocCqH22FiUCR6jRy2OwtCRus=
+modernc.org/libc v1.75.6/go.mod h1:bO5o2ztHxBb2rjz0PgdHN0sSMw57CgxGFLZ3Qd/QpVQ=
modernc.org/mathutil v1.7.1 h1:GCZVGXdaN8gTqB1Mf/usp1Y/hSqgI2vAGGP4jZMCxOU=
modernc.org/mathutil v1.7.1/go.mod
h1:4p5IwJITfppl0G4sUEDtCr4DthTaT47/N3aT6MhfgJg=
-modernc.org/memory v1.11.0 h1:o4QC8aMQzmcwCK3t3Ux/ZHmwFPzE6hf2Y5LbkRs+hbI=
-modernc.org/memory v1.11.0/go.mod
h1:/JP4VbVC+K5sU2wZi9bHoq2MAkCnrt2r98UGeSK7Mjw=
+modernc.org/memory v1.12.1 h1:nFMiWrpStgZczNl6XI9GnIk/rWhYIyHGUaR04pGbp9g=
+modernc.org/memory v1.12.1/go.mod
h1:/JP4VbVC+K5sU2wZi9bHoq2MAkCnrt2r98UGeSK7Mjw=
modernc.org/opt v0.2.0 h1:tGyef5ApycA7FSEOMraay9SaTk5zmbx7Tu+cJs4QKZg=
modernc.org/opt v0.2.0/go.mod h1:03fq9lsNfvkYSfxrfUhZCWPk1lm4cq4N+Bh//bEtgns=
modernc.org/sortutil v1.2.1 h1:+xyoGf15mM3NMlPDnFqrteY07klSFxLElE2PVuWIJ7w=
modernc.org/sortutil v1.2.1/go.mod
h1:7ZI3a3REbai7gzCLcotuw9AC4VZVpYMjDzETGsSMqJE=
-modernc.org/sqlite v1.57.0 h1:qNQP6xnx5M0ISNtlnxoOX0+cD5bJ0/gr9aMmndFczzg=
-modernc.org/sqlite v1.57.0/go.mod
h1:yCJ2cmAaIkHQ25oXWrF8H4O1lIfPYPR26yCEDj2P3pQ=
+modernc.org/sqlite v1.58.0 h1:38u40/bwkfM7f0Myhosl+SEMltSDxnGdQf8o6Kjmys0=
+modernc.org/sqlite v1.58.0/go.mod
h1:rsD2CckafgObKC4DhBlGBf+RiHxkc3hINGt1Xw32tVY=
modernc.org/strutil v1.2.1 h1:UneZBkQA+DX2Rp35KcM69cSsNES9ly8mQWD71HKlOA0=
modernc.org/strutil v1.2.1/go.mod
h1:EHkiggD70koQxjVdSBM3JKM7k6L0FbGE5eymy9i3B9A=
modernc.org/token v1.1.0 h1:Xl7Ap9dKaEs5kLoOQeQmPWevfnk/DM5qcLcYlA8ys6Y=
