That sounds like a bug. Can you create a GH issue with a small repro case so I can investigate @U04DSRYBQ3H? Thanks.

It's been discussed from time to time. There was a GH issue created years ago to discuss it (but ultimately closed): https://github.com/seancorfield/honeysql/issues/146

I think "massive" and "sprawling" are apt words for this idea 🙂

I see. One thought came to mind, is this a reasonable approximation\starting place?

Hmm that looks off

Hahaha... I wouldn't trust ChatGPT any further than I could throw it... it very confidently produces incorrect code... sometimes it's obviously incorrect, sometimes it's just subtly incorrect.

Not unreasonable, but it was worth a shot as a starting place. If I were to begin such a project I'd probably start very small with a separate library and get at least one type of query covered to publish and see community interest\attract collaborators.

It's completely wrong about strings -- HoneySQL uses keywords or symbols. Strings are values that are generally lifted out as parameters.

On the other hand, it's not like the dbs it targets doesn't tell you exactly what's wrong with the resulting sql if it's invalid

DDL syntax is horrifically variable across databases and HoneySQL supports a lot of it by basically assuming "you know what you're doing" and accepting fairly arbitrary sequences of keywords and (sub-)sequences of stuff.

I see. Probably not worth the trouble

https://cljdoc.org/d/com.github.seancorfield/honeysql/2.4.1002/doc/getting-started/sql-clause-reference#create-table-with-columns and https://cljdoc.org/d/com.github.seancorfield/honeysql/2.4.1002/doc/getting-started/sql-special-syntax-#column-descriptors should give you an idea of how... flexible... create table syntax can be 🙂

There's also the interesting issue that there are plenty of valid-to-HoneySQL data structures that produce absolute garbage SQL -- and what's valid SQL for one DB might be invalid for another DB, just to add to the fun.

Yeesh yeah I'm tapping out. Thanks for humoring me 😛

A spec could be useful for invalid-to-HoneySQL data structures. Consider a few examples:

=> (honey.sql/format {:select [[[:array #{}]]]})
Execution error (ExceptionInfo) at honey.sql/format-expr-list (sql.cljc:483).
format-expr-list expects a sequence of expressions, found: class clojure.lang.PersistentHashSet
;; ^ Doesn't let you know the context where the set was found, could problematic to quickly find when you have a lot of dynamic parameters.

=> (honey.sql/format {:where nil})
Execution error (ExceptionInfo) at honey.sql/format-dsl (sql.cljc:1258).
These SQL clauses are unknown or have nil values: :where
;; ^ Obvious with this simple query but hard to find with deeply nested SQL with a lot of dynamic `:where`

=> (honey.sql/format {:select [[[:raw "(" 1 ")"]]]})
["SELECT ("]
;; ^ No error but still incorrect usage of `:raw` which might potentially even produce syntactically correct SQL, making it hard to debug.

To be fair with those first two, ex-data helps here (I should mention that in the docs):

user=> (honey.sql/format {:select [[[:array #{}]]]})
ExceptionInfo format-expr-list expects a sequence of expressions, found: class clojure.lang.PersistentHashSet  clojure.core/ex-info (core.clj:4739)
user=> (ex-data *e)
{:exprs #{}}
user=> (honey.sql/format {:where nil})
ExceptionInfo These SQL clauses are unknown or have nil values: :where  clojure.core/ex-info (core.clj:4739)
user=> (ex-data *e)
{:where nil}

I need to think about :raw -- I suspect that was an unintended (or poorly thought out) change from 1.x 😕

Ah, right. But still - it shows just the value, not where it is. It's already helpful but having a "data stack trace" (i.e. a get-in-like path) would be even more helpful.

I could probably create something from the stacktrace, walking back for honey.sql$format_ matches (on invokeStatic) to report a better context there, since it is full-on recursive descent formatting. :thinking_face:

https://github.com/seancorfield/honeysql/issues/476 and https://github.com/seancorfield/honeysql/issues/477