glimr_postgres/postgres

PostgreSQL Adapter

Application boot needs to wire up database pools, cache pools, and session stores. This is the public entry point — 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. Pool construction, query execution, and session storage all live here so callers only need to import this one module.

Types

Re-exporting pog.Connection under a local alias lets the rest of the codebase reference Connection without depending on pog directly, so swapping the underlying driver only requires changes here.

pub type Connection =
  pog.Connection

The pool must be opaque so callers can’t bypass the checkout/checkin protocol by accessing the raw connections directly. Storing closures rather than an Erlang PID keeps the Erlang pool internals hidden from Gleam code.

pub opaque type Pool

The Erlang FFI returns closures that capture the pool handle internally, so a named record type is needed to receive them across the FFI boundary. This stays public so the FFI module can construct it.

pub type PoolOps {
  PoolOps(
    checkout: fn() -> Result(
      #(pog.Connection, fn() -> Nil),
      String,
    ),
    stop: fn() -> Nil,
  )
}

Constructors

  • PoolOps(
      checkout: fn() -> Result(#(pog.Connection, fn() -> Nil), String),
      stop: fn() -> Nil,
    )

Values

pub fn session_store(pool: db.DbPool) -> session.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.

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.

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.

Search Document