Thank you, this is exactly what I needed.

@U04V70XH6 In HoneySQL v1 I had got a function like this: (defn build-select [table-name where limit] (hsql/format (hsql/build :select :* :from table-name :where where :limit limit))) All this was valid thanks to the build fn: (build-select :public.table) (build-select :public.table [:= :table.field "string"]) (build-select :public.table [:= :table.field "string"] 10) Now I changed the logic in HoneySQL v2 to this - so I can supply map with/out :where or :limit as before. (defn build-select [table-opts] (hsql/format (merge {:select [:*] :from [(:table-name table-opts)]} (select-keys table-opts [:where :limit])))) The input got a little different of course: (build-select {:table-name :public.table}) (I am building custom sql queries from EDN files. I used to read list of [table-name where limit] now it is (:table-name string :where vector :limit int}

Well, it’s “just data” so you can use cond-> and assoc to conditionally add things, or use the helper functions to make sure you get the right structure.

@zikajk BTW, if you’re reading a vector of [table-name where limit] you can always turn that into a map programmatically with (zipmap [table-name where limit] [:table-name :where :limit]) or your build-select could take [[table-name where limit]] as before and do (hsql/format (cond-> {:select [:*] :from [table-name]} where (assoc :where where) limit (assoc :limit limit)))

(in case you wanted to preserve the calling format)

@U04V70XH6 Thank you. I already changed my code to use maps, no problem here. It is just that build fn is one of the first thing mentioned in HoneySQL v1 tutorial so I have been looking for it (as I migrated to version2 because of {:inline true} which is a great option btw.)