Knex.js and an externally managed pg.Pool: who owns transaction connection acquisition?

I am setting up a repeatable development environment for a Node.js service backed by PostgreSQL, and I need to decide how Knex.js (assume a current 1.x/2.x line) should share connection management with the underlying pg driver.

My understanding is that when no pool option is given, Knex builds its own generic-pool wrapper (default min 2, max 10), but when I pass a pre-created pg.Pool instance via the pool config key, Knex delegates acquisition to it entirely. I want one shared pool across the app so connection counts stay predictable against a small local Postgres instance, and I want transactions to hold exactly one connection for their full duration.

What is unclear to me is the contract at this boundary: whether passing an external pool risks any double-pooling behavior, whether Knex's transaction logic still guarantees single-connection checkout when the pool is externally owned, and whether introspecting pool state through knex.client.pool is stable enough to rely on for a dev-environment health check, given that its shape appears to differ depending on configuration and possibly version.

Specifically:

• Is supplying a custom pg.Pool a documented, supported way to make Knex delegate pooling, or is it an internal seam?
• With an external pool, does knex.transaction() still pin one connection for the transaction's lifetime?
• Is there a supported way to read pool statistics without depending on the internal knex.client.pool structure?