glimr_postgres/postgres

PostgreSQL Adapter

Application boot needs to wire up database pools, cache pools, and session stores, but the underlying config parsing and pool construction are spread across several internal modules. This is the public entry point that ties them together — each function takes a name or pool and returns a ready-to-use resource, so the app’s main module reads as a simple sequence of start calls rather than manual config loading and plumbing.

Values

session_store

</>

pub fn session_store(pool: db.DbPool) -> store.SessionStore

If you’re already running Postgres, storing sessions there avoids adding Redis just for session state. Pass the result to session.setup() in your bootstrap and sessions live in the same database as your application data — one fewer service to manage in production.

start

</>

pub fn start(name: String) -> db.DbPool

The one-liner every app’s main module calls at boot. Loads database.toml, finds the named connection, and starts a pool — no config parsing or driver types to deal with. The assert crash is intentional: a broken database connection at startup is unrecoverable, and crashing immediately gives a clear stack trace instead of propagating errors through every downstream function that tries to use the pool.

start_cache

</>

pub fn start_cache(
  db_pool: db.DbPool,
  name: String,
) -> cache.CachePool

If you’re already running PostgreSQL for your app, you can use the same database for caching instead of adding Redis as another dependency. This wires your existing database pool into the framework’s cache system using a regular SQL table — same CachePool API, no extra infrastructure to manage.