proposal: improve handling positional parameters in `WHERE`

[sio4]

Consider fixing the behavior of positional argument handling. supporting both variadic arguments and slice with values is very confusing and it can be confused to users. Possible directions (without deep consideration) are:

• match the number of ? and number of arguments and allow slices
• support named arguments
• creating another helpful method for IN to reduce complexity and easy usage

---

in sql_builder.go line 91 already calls out to sqlx.In to do an expansion that supports multiple IN statements. The removed section duplicated behavior

Roughly, they look the same, but we need to see them in a logical context. The "removed section" basically do a similar job, but the target statement is totally different. In the SQL Builder, the function takes a whole generated SQL statement so the statement could have multiple ?, so matching them with multiple arguments is not easy (a single value or slice per each ? could help this though). Previously we had a related issue [2] and PR [3] to fix it, and this change will bring that issue again.

This constitutes a breaking change. I think it is worth it, but I am not sure if you want to have a deprication time that warns about the change in behavior, and wait until at least next major release.

Yes, this could be a big breaking change since .Where() could be one of the most popular methods for users, and they mostly use it with variadic arguments. Also, if we change this way completely, there are more things to be fixed with it to make it works.

Some references:

• [1] 5e912b0 support "in" queries
• [2] bind vars generation failed when use both WHERE + IN and HAVING. #65
• [3] Improved the "in" support #67
• [4] Query in support with slice args. #267

Originally posted by @sio4 in #524 (comment)