Can you explain the "mistake" in a bit more detail? When I hear "inline" and "mistake", I think of :inline putting the values into the SQL string. But I don't think that's what you mean?

The only reason I can think of that you might prefer :params over values in the DSL is for caching purposes (but I don't think many people use the caching system because of the restrictions it places on IN and ARRAY etc).

FWIW, I've never used named parameters with HoneySQL in my own code.

For one, I cannot use caches, other part is that after experimenting a bit I found it easier to compose queries from bigger re-usable bits when parameters were involved. The last bit is because I have to work with JSONB there's a lot of :inline all over the place that I can avoid if I switch to named parameters

Hmm... :inline? Why? Wouldn't you use :lift to wrap JSON-like data inside the DSL? I'm curious about the use case to see if I can make it easier...?

ah sorry, I meant :lift (it's been a long day) , but yes - I do have a lot of :inline too (for example when querying for boolean fields [:= :u.deleted [:inline false]] or constructing objects from sub-queries/joins [:json_build_object [:inline "id"] :u.id] )

but named parameters won't help here anyway

is there any sort of benifit in inlining the input instead of just passing it?

Small benefit for me is that all my queries ignore records that are marked as deleted, and there's no way to override that - so inlining boolean conditions guarantees that