Difficulty providing container types as bound parameters

[LouisGariepy]

Discussed in https://github.com/cornucopia-rs/cornucopia/discussions/139

^{Originally posted by skreborn August 4, 2022} 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 a Vec<String> that has to be converted to a &[&str] before binding. It only gets worse when I wrap it in an Option.

This introduces some awful code duplication because I constantly have to fight the borrow checker, when postgres would happily accept my Option<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, as postgres has ToSql 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.

[Virgiel]

~~I had an idea using traits in #78. We would have:~~

• StringSQL: &str, String, Cow
• BytesSQL: &[u8], Vec<u8>, Cow
• ArraySQL: &[T], Vec<T>, Cow

~~The problem with Trait is that either we use &dyn wich is easy to use but can impact performance (we could benchmark it), or we use generic functions and structs. For functions, we can use impl Trait but not yet for struct and generating generic code is complex but we could try.~~

I'm trying to get it to work with &dyn, it's much harder than I thought. If anyone has another idea, I'm interested

[Virgiel]

We need something that works well with Option and arrays. And traits are a nightmare for that.

[skreborn]

Any chance we can get away with wrapper enums for these types?