- Notifications
You must be signed in to change notification settings - Fork516
Add table_oid and column_id to column structure of prepared statements#1084
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
388c7b7
to8787615
Compare@sfackler Sorry for bothering you. Is there a chance this PR could be merged soon? I'm in need of this feature for an upcoming code generation tool for type safe queries based on tokio-postgres. |
Thanks! Sorry for the delay. |
sfackler commentedDec 12, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Hmm, actually I think I'm going to adjust the return values to |
@sfackler Is there a chance you could release a new I plan on releasing my crate in 1-2 weeks so a release of |
I want to access the underlying table and column of a query and found those two information not exposed in the
statement::Column
structure.I also simplified the
Debug
implementation ofColumn
by usingr#type
rather thantype_
so#[derive(Debug)]
can be used. As the argument list grew longer I also removed thenew
method in favor of making all the fieldspub(crate)
.Should we maybe expose the three remaining fields as well?
type_size: i16
type_modifier: i32
format: i16
I don't have an immediate need for them. They could provide useful in the future, though.
What are your thoughts on using
NonZeroU32
andNonZeroI16
? I'm not 100% sure if that's really a good choice for the type. Yet it felt somewhat natural to use it as0
denotes that this information is not available.