This would potentially reduce the effect of statement-caching + increase the parsing overhead of your queries (server-side). But this might not be that important

I don't know where the overhead will come from given that there's plenty of instance?-like checks there already, but the point about caching is a good one, I haven't thought of it. Still yet to use caching in my projects.

When using postgres, statement-caching is enabled by default. I found https://dev.to/yugabyte/postgres-query-execution-jdbc-prepared-statements-51e2 to be an excellent explanation

Ah, we're talking about different caches. That's good to know about JDBC. But HoneySQL itself has a cache: https://cljdoc.org/d/com.github.seancorfield/honeysql/2.4.980/doc/getting-started/general-reference?q=cach#caching

Right - yeah I was not thinking about that 🙂

I believe tha eg Oracle keeps several caches around for performance. Eg a query needs to be planned. If you use prepared statements, (again, I believe) that each instance of the prepared statement gets the same plan, whereas if you inline the params, it’d need to create a plan for each instance.

Right now, HoneySQL doesn't know how to inline dates anyway so that would have to be fixed first... 😕

(and its not clear what that would need to look like for ClojureScript)