Austin Bonander

> It's timestamp is the maximum of all the timestamps in `.old`. While this is clever, I don't want to place a restriction on version numbers. In fact, I rather...

We unfortunately have no way to do this right now while keeping the guarantee that output columns and types match the field names and types in the struct. We could...

Ah, thanks. `const_panic` is still a necessary feature for this, though, otherwise we can't control the error message. There's been some promising discussion on the tracking issue so I think...

> Could we at least document this currently for now? As It was not clear for me. This is already stated in the documentation: https://github.com/launchbadge/sqlx/blob/master/src/macros.rs#L379 This is also stated in...

The documentation also goes on to explain, pretty clearly I think, how the macro maps rows to the struct. However, "no trait implementations are required" can be misleading because `Decode`...

Also try switching from `runtime-tokio-rustls` to `runtime-tokio-native-tls`

As context for how we handle this in our applications (as SQLx is a core component of many Launchbadge projects), we usually have a little extension trait over `Result` like...

I could see possibly introducing a `kind()` method and enum, though I think there should also be some convenience methods like: ```rust fn is_constraint_violation(&self) -> bool; fn is_unique_violation(&self) -> bool;...

Yeah, feel free.

This has been something I've wanted to improve for a while. I'm not entirely sure why, but parse errors from SQL are just generally awful, regardless of flavor. I imagine...