pgx / pgxpool Interceptors aka Middleware (for caching, circuit breakers, etc.)

[StevenACoffman]

Problem Statement: Generic Interceptor (e.g. Caching)

The pgx interface is faster than the database/sql interface. The pgx interface is faster. Many PostgreSQL-specific features such as LISTEN / NOTIFY and COPY are not available through the database/sql interface.

However, ngrok/sqlmw provides database/sql interface interceptors (middleware).

This has facilitated use cases like prashanthpai/sqlcache which provides a nice declarative mechanism for caching individual queries to improve performance. Other use cases like circuit breakers, retry mechanisms, etc. are also facilitated by having generic interceptor interfaces.

Specifically, I want to write an interceptor using the pgx / pgxpool interface that would provide for sqlcache, so that when the cache misses it would still use the faster pgx interface, and allow PostgreSQL-specific features.

Describe the solution you'd like
A package like ngrok/sqlmw specific to pgx / pgxpool to facilitate a generic caching layer like prashanthpai/sqlcache without resorting to the database/sql interface.

prashanthpai/sqlcache relies on query "annotations", like so:

-- name: GetUsers :many
-- @cache-ttl 30
-- @cache-max-rows 10
SELECT * FROM users;

[jackc]

I'm open to additional extension points, but the proposal would need to be more specific.

There are already several extensions points that overlap with a generic middleware, the tracing interfaces and the QueryRewriter interface in particular. Any new system would need to play nice with the existing architecture.

In addition, it should be something that has significant advantages over a wrapper or container. For example, with caching in particular, I would usually assume that caching would be more effective at a higher layer. That is, the final domain objects are cached, not the low-level row data that needs to be reparsed.

[StevenACoffman]

That's actually two great points.

Moving caching/retry/circuit breaker decisions outside of the driver (e.g. sqlc generated Go code) would perform even better by avoiding reparsing of the SQL.

Also, it's probably a better pattern to make cache domain objects.