You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is used as a shorthand when interacting with raw OIDs, but causes issues with regular code. Postgres does not support unsigned integers natively, but because of this impl it is easy to pass a u32 accidentally when binding values.
This is not a theorical footgun: it occurs to me every few months to get bitten by this.
Most recently, I had a bunch of code expecting a INT8 CHECK (VALUE >= 0) but forgot to use i64::from(some_input_u32) and managed to get a memory corruption on Postgres (because of unexpected argument buffer sizes).
The solution is simple: define an Oid(u32) wrapper type and implement the type-related traits on Oid instead of u32. It would make it more explicit when using a Oid and prevent these kinds of errors when using a bare u32.
Sqlx currently implements
Type<Postgres>
on theu32
primitive (and related types):sqlx/sqlx-core/src/postgres/types/int.rs
Line 77 in 9abe9b3
This is used as a shorthand when interacting with raw OIDs, but causes issues with regular code. Postgres does not support unsigned integers natively, but because of this impl it is easy to pass a
u32
accidentally when binding values.This is not a theorical footgun: it occurs to me every few months to get bitten by this.
Most recently, I had a bunch of code expecting a
INT8 CHECK (VALUE >= 0)
but forgot to usei64::from(some_input_u32)
and managed to get a memory corruption on Postgres (because of unexpected argument buffer sizes).The solution is simple: define an
Oid(u32)
wrapper type and implement the type-related traits onOid
instead ofu32
. It would make it more explicit when using aOid
and prevent these kinds of errors when using a bareu32
.EDIT: This is a breaking change, but could be part of the
6.00.6.0 release.The text was updated successfully, but these errors were encountered: