Not in general. {:select :*} is valid in both versions.

that's what I thought. we're transitioning our code base to using v2, but we have a lot of v1 and I want to verify that a given version uses the right formatter

You can add metadata to a map to signify that it came from v2, use that metadata in the formatter, and after a full transition, drop the metadata altogether.

I'd be interested in specific migration cases you're running into that I could make easier... there's already honey.sql/call so that v1 (call f args) continues to work -- but none of the types/protocols from v1 are present in v2, so a lot will depend on what you're actually using in v1.

For most uses, the DSL is unchanged and v1 DSL data should "just work" with v2. But the v2 DSL is much more capable.

The issue is more that when a function returns a honeysql map, you have to look at the code that generated the map to know which formatter to use. I can't pass v1 to v2 for fear of #sql/params or #sql/raw messing us up. Likewise, we've added some extensions to v2 that aren't available in v1, so passing in a v2 map to v1 formatter will produce incorrect sql or blow up as well. Nothing negative has happened yet, I'm just hoping to catch such mistakes as early as possible.

i just checked and we have non-symmetric extensions for both v1 and v2 lol

That's... unfortunate 🙂

Regarding the data readers... I probably could provide those in v2 with "equivalent" implementations (although :raw is more powerful and quite a bit less "weird" in v2). Feel free to open issues on GH.

We're not going to be switching by just swapping the required library in the ns form, so I don't think you should add data readers

FWIW, at work, as we're migrating piecemeal from v1 to v2, we've generally been able to switch one ns at a time because we tend to construct the DSL and format it in the scope of a single ns -- because we've avoided the "temptation" to have a "convenience" function that does format + run query (which I think is an anti-pattern of usage, TBH).

(we were also very careful with v1 to avoid the readers -- I never liked them in the first place)

You've said that before but I don't understand why you think it's an anti-pattern. I experimented last year with switching one of our fmt-and-query functions to require explicit formatting, and it provided no help except that I added ~400 calls to (sql/format) to the calls

Because now your fmt-and-query function is explicitly tied to a specific version of HoneySQL 🙂

i guess a fmt-and-query-v2 doesn't phase me. a handful of lines for the function saves a lot of boilerplate when making queries