Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged

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 thestatement::Column structure.

I also simplified theDebug 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 usingNonZeroU32 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.

@bikeshedder
Copy link
ContributorAuthor

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

Thanks! Sorry for the delay.

@sfacklersfackler merged commiteb3f595 intorust-postgres:masterDec 11, 2023
@sfackler
Copy link
Collaborator

sfackler commentedDec 12, 2023
edited
Loading

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

bikeshedder reacted with thumbs up emoji

@bikeshedder
Copy link
ContributorAuthor

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

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

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@bikeshedder@sfackler

[8]ページ先頭

©2009-2025 Movatter.jp