Module pg 

Postgres-backed L2 durable cache tier StorageBackend.

This is the shared, durable middle tier of the tiered super-cache resolver (Redis L1 → Postgres L2 → object L3). Where RedisBackend is an ephemeral hot cache whose keys may vanish under maxmemory LRU, the Postgres tier is authoritative: a narinfo/NAR written here survives a pod roll, and PgStorageBackend::list_narinfos returns the full set of keys, not a hot subset.

Two Postgres axes, one crate, do not confuse them

There are two Postgres-backed content-addressed surfaces in the sui workspace, on different traits:

• This PgStorageBackend — a StorageBackend (the binary-cache blob axis: narinfo strings keyed by store-path hash, NAR blobs keyed by relative URL). It is the L2 tier of TieredBackend.
• [sui_store::PgStore] — a sui_store::Store (the durable nix-store axis: StorePath → PathInfo + NAR data, content-addressed by GraphHash). It is the sibling that the on-disk graph store migrates onto.

Both are Postgres, both content-addressed, different traits, different key shapes. This module is the cache one.

The connection seam (Environment / testability contract)

PgStorageBackend is generic over PgCacheConn — the minimal typed row-verb surface it needs (select / upsert / delete / keys over a typed PgTable). Unit tests inject an in-memory mock; production injects [SqlxPgCacheConn] (a real sqlx Postgres pool, behind the postgres feature). The full L2 mapping — the two-table split, the content-addressed keying, typed UTF-8 handling, the delete NAR-pattern fan-out — is proven against the mock with no live Postgres required.

Structs

PgStorageBackend

L2 durable cache tier: content-addressed key → value over Postgres, shared across pods, survives a roll.

Enums

PgTable

The two logical tables the cache tier keeps: narinfo text and NAR blobs.

Traits

PgCacheConn

The minimal typed Postgres row-verb surface PgStorageBackend depends on.