Why is it that prepared statements can only be executed on a PgConn, not on a pgxpool.Pool?

[nunoki]

pgxpool.Pool has an Exec method, but not ExecPrepared. The ExecPrepared method is only defined on a pgconn.PgConn, but the doc for retreiving it via pgxpool.Conn.PgConn() says that it's an escape hatch method, making it sound like its usage is discouraged.

I don't know if there is a technical reason why prepared statements shouldn't or cannot be used on a connection pool, or if I am just misunderstanding the intended usage?

[jackc]

Direct usage of prepared statements on a pgxpool.Pool (or any connection pool) is slightly tricky because prepared statements are strictly at the connection layer in PostgreSQL. That means something has to keep track of which statements are prepared on which connections.

---

You can manually use prepared statements with a pgx.Conn. You don't have to go down to the pgconn.PgConn level.

However, by default pgx automatically prepares statements and keeps a cache of statements. So the recommendation is that unless you have a very particular or unusual use case that you don't manually do any prepared statements.

If for some reason you really did need to ensure prepared statements were used and you had to use pgxpool.Pool then the way to do that would be to acquire a pgx.Conn from the pool and call Prepare and the query method on the pgx.Conn. Prepare is a no-op if the statement already exists on that pgx.Conn so there is no performance hit. But again, it is unlikely that you need to manually use prepared statements at all.