- Notifications
You must be signed in to change notification settings - Fork515
Implement FromSql for tuples up to length 4#626
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
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This makes it very ergonomic to decode the results of a query like SELECT (1, 'a')where (1, 'a') is returned as an anonymous record type.The big downside to this approach is that only built-in OIDs aresupported, as there is no way to know ahead of time what OIDs will bereturned, and so we'll only have metadata for the built-in OIDs lyingaround.
AtsukiTak commentedNov 9, 2020
Looks great! I'm very interested in this feature! I hope this PR will be merged! |
skreborn commentedJun 22, 2021
@sfackler Is there anything - other than a rebase - that prevents this from being merged? I agree thatat least 8 tuple items should be supported, but adding huge numbers seems excessive for a first implementation. We can always add more (behind feature flags) later, building on this PR. Right now, we're forced to implement this ourselves, and it would help tremendously to have built-in support for tuples. |
WGH- commentedMar 27, 2022
This is a useful feature. Maybe not so on its own: who writes But if you do things like |
-rust-postgres#626 with feature gate additions
This makes it very ergonomic to decode the results of a query like
where (1, 'a') is returned as an anonymous record type.
The big downside to this approach is that only built-in OIDs are
supported, as there is no way to know ahead of time what OIDs will be
returned, and so we'll only have metadata for the built-in OIDs lying
around.
Fix#310. Also related to#366 and#565.