add *sql.DB construction from *pgxpool.Pool

[lzakharov]

Closes #1065

[jackc]

There seems to be a great deal of code. I would not have expected a sql.DB <-> pgxpool.Pool adapter to be more than 50 LOC. stdlib already uses *pgx.Conn internally. I would have expected a small shim for stdlib that uses pgxpool.Pool.Acquire instead of pgx.ConnectConfig and pgxpool.Conn.Release instead of pgx.Conn.Close.

[lzakharov]

Agree, started to make this solution as a separate module, that's why I had to duplicate a lot of code. Rewrote to a more compact version.

[redbaron]

whats the use case for sql.Driver level BeforeAcquire? Pool already has this callbacks internally.

[lzakharov]

This is a good point, fixed!

[lzakharov]

@jackc can u review again, please?

[jackc]

The code seems reasonable.

But this approach requires the database/sql pool to be configured with SetMaxIdleConns or the like to avoid acquiring all the connections from the pgxpool and starving any direct users of the pgxpool.

At the very least proper usage should be documented. But if SetMaxIdleConns(0) should always be called, maybe OpenDBFromPool should call it automatically.

[redbaron]

At the very least proper usage should be documented. But if SetMaxIdleConns(0) should always be called, maybe OpenDBFromPool should call it automatically.

It does: https://github.com/jackc/pgx/pull/1718/files#diff-32dbcc70c656d819ec542b81ab30702bb835f38d8db8c0574c6da16b7ce04b35R229

[zekth]

I did just try this branch in integration with a project using bun https://github.com/uptrace/bun And perfectly works.

[jackc]

At the very least proper usage should be documented. But if SetMaxIdleConns(0) should always be called, maybe OpenDBFromPool should call it automatically.

It does: https://github.com/jackc/pgx/pull/1718/files#diff-32dbcc70c656d819ec542b81ab30702bb835f38d8db8c0574c6da16b7ce04b35R229

@redbaron Huh, not sure how I missed that.

[jackc]

LGTM

[GoosvandenBekerom]

When can we expect the next version to be tagged / released?
Would love to use this!

[lzakharov]

The answer can be found in #1767:

I expect v5.5.0 to be released within a few weeks.

[eamora-ab]

The only thing I don't like is the inability to return the correct DBStats from the pool *sql.DB
Is that still the case?

If this it I'd like to see if there would be a way to get those stats (critical for pool tuning)