Because Go uses the same provided abstraction layer for all SQL databases. If the errors are in the abstraction layer and not the driver it would be odd for them to be MySQL specific.
If you've ever looked at an ORM or even complex MicroORM that supports multiple database you get an appreciation for how many 'little' differences everyone has in the SQL standard itself.
And if that's the "industry standard" (Yeah, I know it's not, but it's at least a spec/guideline) with that much deviation, I can only imagine how dissimilar each DB's nonstandard protocol might be.
I could see GP's comment as a way of exploring the problem in order to get a better grasp on the technical or architectural choices that may have caused the difference in outcome, in order to potentially learn what's important about how to design things like connection pooling.
Yeah, we use Go with Postgres a lot, so I'm wondering if we should check for all these problems on Postgres as well. And if we don't, why? What so different about the PG connection models that this problem won't happen there? The principles are all the same, and QueryContext changes apply equally to all database adapters.
