-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved detection of nullability for postgres #696
Comments
Another (related?) issue: sqlx thinks this is an query!(
"INSERT INTO doc_coverage (release_id, total_items, documented_items)
VALUES ($1, $2, $3)
ON CONFLICT (release_id) DO UPDATE
SET
total_items = $2,
documented_items = $3
RETURNING release_id",
release_id,
doc_coverage.total_items,
doc_coverage.documented_items,
)
.fetch_one(conn)
.block()?
.release_id |
@jyn514 can you provide a We can feasibly detect simple cases like |
That's unfortunate ... I don't want to make you add a full parser (I know one of the goals of the proc-macros is to avoid having to do that), so if this is too hard to support it's not a blocker for us. |
This query currently returns an
Option<i64>
. It would be nice to instead returni64
, becauseCOUNT
is never nullable.@mehcode mentioned that I can give SQLx a type hint by using
r#"SELECT COUNT(*) as "count!" FROM crates;"#
; this is a good workaround in the meantime but I'd love for sqlx to be able to figure it out itself. A possible implementation is to select from a temporary table or view and get the nullability from that view.The text was updated successfully, but these errors were encountered: