Replies: 1 comment 1 reply
-
Thanks for reporting. There indeed seems to be a lack of ergonomics here. I'll think this through and open a PR soon! |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
At the moment, it's difficult to provide container types such as wrappers (
Option
) and collections (Vec
) as bound parameters, because everything has to be converted to a borrowed version. This is most annoying in the case of aVec<String>
that has to be converted to a&[&str]
before binding. It only gets worse when I wrap it in anOption
.This introduces some awful code duplication because I constantly have to fight the borrow checker, when
postgres
would happily accept myOption<Vec<String>>
as-is (as far as I can tell at least).I'm unsure what would be the proper solution to this problem. At least for
String
and&str
values,Cow
could be used, aspostgres
hasToSql
implemented for it.Another approach could be to create a separate borrowed and owned parameter struct, much like when returning results. This way, the library user could make the conscious decision to lean either way - whichever works for them.
Beta Was this translation helpful? Give feedback.
All reactions