You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'd like to be able to maintain only a stable struct mapping (with no special interfaces) even when using a composite type in the query.
Describe the solution you'd like
I think this should be reasonable. The composite pgtype appears to have access to the column names, given that a "default" behavior (or new interface to meet) seems like it could use reflection to match to struct fields (by tag/default) instead of requiring field index matching.
Describe alternatives you've considered
I've implemented by meeting the existing interface, but it ends up creating friction when the rest of the struct maps by struct tag.
Additional context
I'm willing to put up a PR for this if the design/idea is valid and fits the ecosystem here!
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'd like to be able to maintain only a stable struct mapping (with no special interfaces) even when using a composite type in the query.
Example (the names aren't great sorry):
I'd like to be able to
Describe the solution you'd like
I think this should be reasonable. The composite pgtype appears to have access to the column names, given that a "default" behavior (or new interface to meet) seems like it could use reflection to match to struct fields (by tag/default) instead of requiring field index matching.
Describe alternatives you've considered
I've implemented by meeting the existing interface, but it ends up creating friction when the rest of the struct maps by struct tag.
Additional context
I'm willing to put up a PR for this if the design/idea is valid and fits the ecosystem here!
The text was updated successfully, but these errors were encountered: