Skip to content
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

Add table_oid and column_id to column structure of prepared statements #1084

Merged
merged 2 commits into from
Dec 11, 2023

Conversation

bikeshedder
Copy link
Contributor

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 of Column by using r#type rather than type_ so #[derive(Debug)] can be used. As the argument list grew longer I also removed the new method in favor of making all the fields pub(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 and NonZeroI16? I'm not 100% sure if that's really a good choice for the type. Yet it felt somewhat natural to use it as 0 denotes that this information is not available.

@bikeshedder
Copy link
Contributor Author

@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.

@sfackler
Copy link
Owner

Thanks! Sorry for the delay.

@sfackler sfackler merged commit eb3f595 into sfackler:master Dec 11, 2023
4 checks passed
@sfackler
Copy link
Owner

sfackler commented Dec 12, 2023

Hmm, actually I think I'm going to adjust the return values to Option<u32> rather than use NonZeroU32. That's what we use elsewhere in the API.

@bikeshedder
Copy link
Contributor Author

@sfackler Is there a chance you could release a new tokio-postgres version. I'm in progress of releasing a crate that does depend on this feature. I can't push this to crates.iounless a new version of tokio-postgres is published first.

I plan on releasing my crate in 1-2 weeks so a release of tokio-postgres would be highly appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants