I have found these related issues/pull requests
I determined from bisecting that 69ee0df from PR #4088 introduces the breaking change.
Description
I have a project with eight INSERT ... RETURNING queries, each of which returns the INTEGER PRIMARY KEY for the inserted row. All eight compile successfully with sqlx 0.8.6. When I upgrade to 0.9.0, five of the eight have compilation errors about their return type.
E.g.:
sqlx::query_scalar!(
"
INSERT INTO projects_data (
project_id,
name,
slug,
description,
game_title,
game_title_sort,
game_publisher_id,
game_year,
game_players_min,
game_players_max,
game_length_min,
game_length_max,
readme,
image
)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
RETURNING project_data_id
",
row.project_id,
row.name,
row.slug,
row.description,
row.game_title,
row.game_title_sort,
row.game_publisher_id,
row.game_year,
row.game_players_min,
row.game_players_max,
row.game_length_min,
row.game_length_max,
row.readme,
row.image
)
.fetch_one(ex)
.await?
gives this error with 0.9.0:
error[E0308]: `?` operator has incompatible types
--> src/sqlite/project.rs:184:9
|
179 | ) -> Result<i64, DatabaseError>
| -------------------------- expected `i64` because of return type
...
184 | / sqlx::query_scalar!(
185 | | "
186 | | INSERT INTO projects_data (
187 | | project_id,
... |
220 | | .fetch_one(ex)
221 | | .await?
| |_______________^ expected `i64`, found `Option<i64>`
|
= note: `?` operator cannot convert from `std::option::Option<i64>` to `i64`
= note: expected type `i64`
found enum `std::option::Option<i64>`
help: consider using `Option::expect` to unwrap the `std::option::Option<i64>` value, panicking if the value is an `Option::None`
|
221 | .await?.expect("REASON")
| +++++++++++++++++
Reproduction steps
I've tried to produce a small test case, but haven't succeeded yet. The project in which I hit this bug reproduces the problem 100% of the time: https://github.com/vassalengine/game-library-service
Switching the Cargo.toml to use sqlx 0.9.0 and running
sqlx database setup
cargo test
is sufficient to produce the compiler errors.
SQLx version
0.9.0
Enabled SQLx features
"macros", "migrate", "runtime-tokio", "sqlite"
Database server and version
sqlite 3.51.2
Operating system
Linux - Fedora 44
Rust version
rustc 1.98.0-nightly (f428d123a 2026-06-19)
I have found these related issues/pull requests
I determined from bisecting that 69ee0df from PR #4088 introduces the breaking change.
Description
I have a project with eight
INSERT ... RETURNINGqueries, each of which returns theINTEGER PRIMARY KEYfor the inserted row. All eight compile successfully with sqlx 0.8.6. When I upgrade to 0.9.0, five of the eight have compilation errors about their return type.E.g.:
gives this error with 0.9.0:
Reproduction steps
I've tried to produce a small test case, but haven't succeeded yet. The project in which I hit this bug reproduces the problem 100% of the time: https://github.com/vassalengine/game-library-service
Switching the
Cargo.tomlto use sqlx 0.9.0 and runningis sufficient to produce the compiler errors.
SQLx version
0.9.0
Enabled SQLx features
"macros", "migrate", "runtime-tokio", "sqlite"
Database server and version
sqlite 3.51.2
Operating system
Linux - Fedora 44
Rust version
rustc 1.98.0-nightly (f428d123a 2026-06-19)