How do you bind a variable-length list of ids to a SQL IN clause with database/sql?

## Why a slice is not one argument A placeholder occupies one slot in the parsed statement and binds one scalar value. `IN (?)` is a list of exactly one element, no matter what you pass, and handing a `[]int64` to it fails at conversion or binds something you did not intend. Since the number of elements changes the *shape* of the statement, the statement text has to change with it — and the only thing that can build that text is your Go code. ## The pattern ```go ph := make([]string, len(ids)) args := make([]any, len(ids)) for i, id := range ids { ph[i] = "$" + strconv.Itoa(i+1) args[i] = id } q := "SELECT id, total_cents FROM orders WHERE id IN (" + strings.Join(ph, ", ") + ")" rows, err := db.QueryContext(ctx, q, args...) ``` Three things are worth naming explicitly: - The loop writes **tokens**, derived only from the index. The ids themselves never touch the string. - `args` is `[]any` because that is what the variadic parameter takes; `args...` spreads it. - On a `?` dialect the body is the same with `ph[i] = "?"`. This is the one place where building a query string with `+` is correct, and it is worth being able to say why in a review: the invariant is not "never concatenate", it is "never let request data reach the statement text". Generated placeholder tokens are program data. ## The empty list `IN ()` is not valid SQL on most engines, so an empty slice must never reach the builder. Decide what an empty filter *means* first — usually "no rows match", occasionally "no filter at all" — and branch before you build. Returning an empty result without touching the database is the common and correct answer; silently dropping the clause turns a filter into a full scan and is how an empty filter set becomes an accidental table dump. ## Size limits and cost Bind parameters are not free and not unlimited. PostgreSQL's wire protocol allows at most 65535 parameters in a single statement, and other engines have their own statement-size and parameter limits. Long before that, a list of tens of thousands of ids is a sign the work belongs in a join against a temporary table or a values list rather than an `IN`. Practical handling: - **Chunk** the list — for example a few hundred to a few thousand ids per statement — and merge the results. - **Pass an array as one parameter** and compare with `= ANY($1)` on engines and drivers that support array parameters. This keeps the statement text constant for every list length, which is a real benefit. - **Join against a temp table** or a driver-side bulk load when the list is genuinely large or reused across several queries. A further consequence of the generated-text approach is that each list length produces a different statement string. That is fine for correctness but it means a cached plan or a prepared statement cannot be reused across lengths, which is another argument for the array-parameter form when it is available. ## Ordering and duplicates `IN` says nothing about result order — you still need an `ORDER BY` — and duplicate ids in the slice are harmless to the filter but waste parameter slots. Deduplicating before building the list is cheap and keeps the parameter count honest. ## Review checklist When you see a generated `IN` clause in a pull request, check four things: the tokens come from the index and not from the values; the values are passed through `args...`; the empty case is handled explicitly; and the list length is bounded by something — a chunk size or an input validation limit — rather than by whatever the caller sends.