In database/sql, how do you Scan rows whose column list is only known at runtime?

## When the select list is not known until runtime Most application code knows its columns at compile time and scans into named variables. A few things do not: a CSV or JSON exporter over an arbitrary `SELECT`, an internal admin query runner, a migration verification tool, a test helper that dumps a table. For those, `database/sql` has exactly the API you need — it is just less obvious, because `Scan` is variadic. ### `Columns` and the two-slice trick `(*sql.Rows).Columns() ([]string, error)` returns the column names of the result set. It is callable after the query has run and errors if the rows are already closed. With the count in hand: ``` cols, err := rows.Columns() if err != nil { return err } vals := make([]any, len(cols)) ptrs := make([]any, len(cols)) for i := range vals { ptrs[i] = &vals[i] } for rows.Next() { if err := rows.Scan(ptrs...); err != nil { return err } // vals[i] is now the value of column cols[i] for this row } return rows.Err() ``` Two slices are needed because `Scan` writes **through** pointers. `vals` holds the values; `ptrs[i]` is `&vals[i]`, a `*any`, boxed into the `any` element type of `ptrs`. The `ptrs...` spread turns the slice into the variadic argument list. A single slice will not do: passing `vals...` hands `Scan` the values, not their addresses, and it rejects them as unsupported destinations. Note that both slices can be allocated once outside the loop and reused, since each `Scan` overwrites every element. If you keep the row — appending it to a result set — you must **copy** `vals` per iteration, or every stored row ends up aliasing the same backing array and holding the final row's values. That is the single most common bug in this pattern. ### What lands in an `*any` Scanning into `*any` asks for no conversion: you receive the value the driver produced. In practice that is one of a small set — `int64`, `float64`, `bool`, `string`, `[]byte`, `time.Time`, or `nil` for SQL NULL. Byte slices are copied into your destination rather than aliasing the driver's own buffer, so a value you keep after the next `Next` is safe. Because the concrete type varies by driver and by column, rendering means a type switch: ``` switch v := vals[i].(type) { case nil: // NULL case []byte: // text or binary the driver did not decode case int64, float64, bool, string, time.Time: _ = v } ``` The `[]byte` case is the one that surprises people: several drivers hand back raw bytes for text columns rather than a `string`, so a generic exporter that only handles `string` will print byte-slice noise for half its columns. ### When names are not enough: `ColumnTypes` `(*sql.Rows).ColumnTypes() ([]*sql.ColumnType, error)` returns richer metadata per column: `Name()`, `DatabaseTypeName()` (the driver's own type name, such as an integer or timestamp type), `ScanType()` (the Go type the driver would prefer), `Nullable()` and length/precision information where the driver supports it. Not every driver populates every method — several return a zero value and a `false` "ok" — so treat the metadata as advisory. Use it when you need to format output faithfully (dates versus numbers) rather than dumping everything as text. ### Everything else about the loop still applies The dynamic form changes only the destinations. You still check the error from `QueryContext`, still `defer rows.Close()`, still check `rows.Err()` after the loop, and `Scan` still errors if the number of destinations does not match the number of columns — which here cannot happen by construction, since you sized the slice from `Columns()`. That is a small, genuine advantage of the pattern over a hand-written select list. ### When not to reach for it This is deliberately unidiomatic for ordinary code. You lose compile-time type checking, you lose the discipline of an explicit select list, and you gain a type switch at every use site. If a caller knows its columns, it should scan into named variables. Reserve the dynamic form for tools whose whole purpose is to handle a query nobody wrote in advance — and be aware that an endpoint accepting arbitrary SQL is an authorisation decision long before it is a scanning problem.