-
-
Notifications
You must be signed in to change notification settings - Fork 235
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
Rewrite string info #903
Rewrite string info #903
Conversation
…s "WhoAllocated" traits. Also adds SAFETY docs. I think it's pretty important for the compiler to have an understanding of who is going to drop a StringInfo, as it's used in the "inoutfuncs" portions of PostgresType, and that's going to get an overhaul soon.
940dabb
to
e44ca3b
Compare
I've rebased this PR. @thomcc, could I get a review? I think this is good cleanup for |
/// Unless `.into_pg()` or `.into_char_ptr()` are called, memory management of | ||
/// this `StringInfo` follow Rust's drop semantics. | ||
pub fn with_capacity(len: usize) -> Self { | ||
pub fn with_capacity(len: i32) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, why the change to the i32
type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I argued with myself over this. Postgres' StringInfo
length is an i32
, so I thought rather than us deal with an usize
that overflows an i32 and have to return a Result, just let the user sort it out ahead of time.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed this on Discord and my sentiment is broadly "usize
is fine and indicates what the input is 'for' to Rust programmers (morally it's actually pg_size_t
), and Postgres is running so many checks that it will throw a fit if we throw a bad input into Postgres, don't worry about it". with_capacity
is really more of an "optimization hint" to Postgres, as Postgres will, before pushing anything on StringInfo, always calculate something that would look like
let needed: c_int = requested_capacity - (sinfo.capacity - sinfo.len);
However, there's an argument that we should either document # Panics
or make anything that throws these numbers directly into Postgres an unsafe fn
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite my stated inclination, I think the type thing can ultimately go either way so I am good with this now.
Rejigger our
StringInfo
wrapper to use a PgBox and honor the various "WhoAllocated" traits.I think it's pretty important for the compiler to have an understanding of who is going to drop a StringInfo, as it's used in the "inoutfuncs" portions of PostgresType, and that's going to get an overhaul soon.
This wants #901 to be merged first.