Support for upcoming driver.RowsColumnScanner interface

[moripaku]

In light of https://github.com/golang/go/issues/67546 that is recently landed in go master branch, please consider adding support for driver.RowsColumnScanner interface in future versions, so custom row scanning capability of sql drivers (pgx in particular) would not be hidden from stdlib layer.

[XSAM]

Hi @moripaku, thanks for the heads up.

~~I am not sure there is anything that needs to be done on the otelsql side, as it does not wrap *sql.DB. So, it does not interfere with the Scan method.~~ (I was wrong after checking the Go source code, https://go-review.googlesource.com/c/go/+/588435)

I would like to support this new interface, but otelsql has a compatibility matrix that needs to support at least two minor versions of Go. The moment to put Go 1.26 as the minimal supported version could be Aug 2026 (the release date of Go 1.27).

[moripaku]

Without the interface support, it would not be possible for pgx to provide scanning of pgx types, extending the dependency on old pq types. Given that pq is adversely affecting tracing by lacking context support on internal methods ( https://github.com/lib/pq/issues/786#issuecomment-479477611 ), it makes sense to aid in ridding of pq completely in context of this project.

There are several options to provide support for such interface without introducing hard dependency:

1. Build tags seem to allow adding support for new types and features without introducing hard dependencies, particularly

a term for each Go major release, through the current version: "go1.1" from Go version 1.1 onward, "go1.12" from Go 1.12, and so on.

as such,

//go:build go1.26

will target >=1.26 and

//go:build !go1.26

will target <=1.25 (and technically >= 1.16, since it was // +build before that)

2. It is possible to define local version of interface, e.g.

type myLocalRowsColumnScanner interface {
	driver.Rows // optional, but for completeness
	ScanColumn(i int, dest any) error
}

without having to depend on stdlib interface version when checking if driver implements such interface, and if go version is 1.25 or less, ScanColumn implementation on otelsql side would simply be never called. Interfaces are just contracts on methods after all, there is no difference between driver.RowsColumnScanner and foo.RowsColumnScanner so long method signatures are the same.

3. Use reflection to check if driver has a method of this specific signature, which is more or less a variant of 2.

[XSAM]

@moripaku Thanks for the well explained proposal! I’d like to use option 1 when Go 1.26 comes out.