Nice! Imho there's little point to make a lib "contrib", please don't .

mapify-result-set feels odd at first glance, why its existence? Is it meant to be public?

something squee/alia have that is quite nice is protocolizing the row construction, sometimes you want a map, sometimes you don't care and might just want the values in order or a seq of tuples etc etc https://github.com/ghadishayban/squee/blob/master/src/squee/impl/protocols.clj#L18-L21 You can also simply make it a reduce like fn signature out of it (0-arity is "mempty", 1-arity is "reduced", 2-arity is "mappend") and allow to optionally pass that fn to "execute"

mapify-result-set is an implementation detail. When I get a bit further into documenting it all, I'll add metadata to a lot of the implementation functions so they do not appear in generated docs.

I've talked with @U050ECB92 about squee and it was some of his input that led to reducible-query in the first place (along with some prodding from @U0NCTKEV8 🙂 )

https://github.com/seancorfield/next-jdbc/issues/2 -- for further consideration

Actually i remember he mentioned using a 3-arity fn "a la reduce" to do this instead of a protocol back then. Personally i prefer a fn over a protocol, it's a quite simple use case

Well, reducible! is the core API in next.jdbc so the expectation is that you use it with reduce and transducers... but, yeah, :row-fn still looks a bit of an odd way to do things now the API is more focused on that.

I've made some changes to the API and the implementation that I think clean this up.

nice, thank you!