This binds `honeysql.format/*subquery?*` to `false` which turns
on processing of a cte-name like `[:foo {:columns [:a :b :c]}]`
resulting in a string like `WITH foo (a, b, c)`.
I forgot that Object doesn't include nil on protocols.
I added test coverage demonstrating the regression, only to note that
parameterized and literal queries produce different sql for the nil
case. I believe only the former is actually valid ANSI SQL, though mysql
at least does not care.
This allows seqs to be used as param values, e.g. for IN clauses. It
also converts sets to seqs for the same purpose.
It does not expand the parameter name when this occurs, which will lead
to a mismatch between the *param-names* and *params* collections. It is
not clear how *param-names* are intended to be used, so I have no better
fix to suggest other than repeating a seq's param name the corresponding
number of times into that collection.
this much-less-invasively fixes the problem I was trying to fix in #48.
In resources/data_readers.clj we direct clojure to use these functions
in honeysql.types to read tagged literals in EDN as SqlCalls, SqlRaws,
and SqlParams. Clojure does this by making a permanent binding to the
Vars for these functions which exist in honeysql.types when it starts
up. The trouble is that if someone is doing REPL-driven development
and calls clojure.tools.namespace.repl/refresh, those vars will be
wholely recreated, along with the deftype classes they point to.
This means that if there's a sql/call in a piece of edn we're reading,
we'll get an instance of the *old* SqlCall class, but if someone just
calls honeysql.types/call they'll get an instance of the *new* class.
These won't match up, and this'll cause some of the tests in core_tests
to fail.
This patch works around that by causing these custom reader functions
to resolve the helpers they call each time they are called, so we
always create instances of the new types if they've been redefined.
Again, this has basically zero effect on the end user, but it removes
a pain-point for someone using REPL-driven development to work on
honeysql itself.
