Austin Bonander
Austin Bonander
@Gankro I can migrate `par_vec`, seeing as I created it
@Gankro Just curious, what would be the procedure to propose a new crate to the group?
@Gankro Yeah I saw that not long after I sent the previous message. I'm looking at the `par_vec` repo and it looks like I can't fork it or submit PRs...
Could we please get one of these packages to try to break the chain here? I just accidentally reintroduced this issue in SQLx 0.5.10 while upgrading dependencies. Keeping a dependency...
The problem is that it appears there won't be any movement on `wasm-bindgen`: https://github.com/tkaitchuck/aHash/issues/95#issuecomment-881503355 So the onus in my eyes falls onto one of the other packages in the chain....
I just closed #1349 as not-planned but it just occurred to me that if we pivot this to being callback that provides `ConnectOptions` on-demand then it can cover both use-cases...
Hmm, that is a problem, yeah. I would probably say that we shouldn't have the callback just return `AnyConnectOptions` in that case as changing database kinds on the fly sounds...
I think the easiest fix would just be to panic if an async `ConnectOptionsProvider` was set. As long as it's well documented I don't see any problem with that.
Closing due to inactivity from the original author. @jamiebrynes7 I don't think I ever saw a PR from you, I'm still interested in your approach.
Alternatively, try this query, which should produce the same results but generate a query plan that's much friendlier to the heuristics: ```sql SELECT todos.* FROM todo_things INNER JOIN todos ON...