The database is hands down the worst in the entire standard library.
Importing a package to pick your driver? Side effects much? Who needs multiple drivers in the same scope anyway?
Consistent behavior or test suits for drivers? nah... why bother.
The database API was poorly thought out. That's why most people use no sql solutions, and what tools do exist for it (eg. test suites) are cobbled together 3rd party collections that have to be manually updated when a new driver is written.
I'm literally flabbergasted to hear someone singing its praises.
I'm confused. sql.Open's first argument is which driver you want to use, in string format. These drivers become available after they've been imported, and the side effects seem insignificant[1]. This seems to make it perfectly possible to use multiple drivers within the same scope. The drivers themselves also seem to have several unit test files, though I can't judge on the quality of those.
See... that's the thing. It might work. If the driver plays nicely. Or it might not. In fact, you have no way of knowing without reading the source code.
The sqlite driver used to not work with the postgres one. I don't know why. I never looked into it... but, that this can happen is pretty bad, I'd argue.
Packages that invoke code when you import them and require this sort of import:
import _ "github.com/go-sql-driver/mysql"
Aren't idiomatic. They're hacks, because the database module didn't really consider how it was going to work properly.
The database is hands down the worst in the entire standard library.
Importing a package to pick your driver? Side effects much? Who needs multiple drivers in the same scope anyway?
Consistent behavior or test suits for drivers? nah... why bother.
The database API was poorly thought out. That's why most people use no sql solutions, and what tools do exist for it (eg. test suites) are cobbled together 3rd party collections that have to be manually updated when a new driver is written.
I'm literally flabbergasted to hear someone singing its praises.