postgres

func WithConn ¶

func WithConn(ctx context.Context, fn func(*pgx.Conn) error) error

WithConn hands the pgx connection behind the effective PostgreSQL connection to fn, so pgx capabilities stay reachable without any pgx type entering the framework API.

The request-time path runs on a pgxpool rather than database/sql, so pw.DB reports no *sql.DB for a PostgreSQL group and sql.Conn.Raw — the escape hatch on the database/sql path — cannot be reached from a handler. This is that hatch for the native path. It serves batches, CopyFrom, and LISTEN/NOTIFY:

err := postgres.WithConn(ctx, func(conn *pgx.Conn) error {
	batch := &pgx.Batch{}
	for _, row := range rows {
		batch.Queue("INSERT INTO t (a) VALUES ($1)", row.A)
	}
	results := conn.SendBatch(ctx, batch)
	defer results.Close()
	for range rows {
		if _, err := results.Exec(); err != nil {
			return err
		}
	}
	return results.Close()
})

Inside pw.Transaction the callback receives the connection that transaction is executing on, so its work joins the transaction and rolls back with it. Outside one, a pooled connection is leased for the call and returned after. Either way nothing derived from the connection may outlive fn: rows must be read, and results closed, before it returns.

Work done here does not pass through the framework's instrumented executor, so it produces no query log entry and no span of its own. Wrap it in one:

ctx, span := pw.StartSpanKind(ctx, "insert-batch", pw.SpanKindClient)
defer span.End()

A group that is not PostgreSQL returns an error naming the dialect it found.