Why not use sql.DB instead of adapter.Tx
dosco opened this issue · comments
Using this adapter.Tx makes it hard to write portable functions it would be best to just use sql.DB instead of adapter.Tx
Adapter generalises db interface because only github.com/lib/pq supports database/sql interface, while github.com/jackc/pgx/v5 and github.com/jackc/pgx/v4 drivers have own interfaces.
That makes sense I endedup writing an adapter for sql.DB so I could use sql.DB with generic functions.
myConnPool := NewConnPool(dbSQL)
tx, err := myConnPool.Begin(c)
if err != nil {
log.Fatal(err)
}
defer tx.Rollback(c)
... use tx in my functionHowever github.com/jackc/pgx/v5 and github.com/jackc/pgx/v4 does work with sql.DB you just have to include them as a driver in your package.
_ "github.com/jackc/pgx/v5/stdlib"
db, err := sql.Open("pgx", "postgres://postgres:@localhost:5432/example_db")
if err != nil {
log.Fatal(err)
}Originally library worked only with pgx so using native driver is more preferred than stdlib wrapper, other drivers were added later, some of them are already gone.
I wonder whether we could have an adapter for sql.DB. This would free me from initialling an extra pgxpool because I already have the sql.DB by importing github.com/jackc/pgx/v5/stdlib for other usage.
I could see the sql.DB adapter will be mostly the same as https://github.com/vgarvardt/gue/pull/139/files#diff-9f1fabd30174ef9b36c0d73790c48b5604600215ccc00167a7896ca086132600
@owenthereal probably you're looking for https://github.com/vgarvardt/gue#libpq
@vgarvardt Ah missed that. Thanks! I was confused by the package name. I would suggest rename the package to stdlib or something
@owenthereal sdlib sql is an interface and several drivers implement it - github.com/lib/pq, github.com/go-sql-driver/mysql, github.com/mattn/go-sqlite3 and some more do, but only the first one works here, so naming the package stdlib or driversql would be even more misleading. In the PR that you referenced I tried to add mysql support, but it simply does not work.