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.
eeeebbbbrrrr
force-pushed
the
rewrite-string-info
branch
from
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.
Hm, why the change to the i32 type?
There was a problem hiding this comment.
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.
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.
Rejigger our
StringInfowrapper 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.