# sqlRunner() function · @imqueue/pg-prisma

Source: https://imqueue.org/api/pg-prisma/latest/pg-prisma.sqlrunner_1/
Published: 2026-08-28
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/pg-prisma 2.0.0 — generated reference, not hand-written

A `query` and a `transaction` that agree about which connection to use.

**Signature:**

```typescript
export declare function sqlRunner(pool: SqlPool): SqlRunner;
```

## Parameters


| Parameter | Type | Description |
| --- | --- | --- |
| pool | [SqlPool](https://imqueue.org/api/pg-prisma/latest/pg-prisma.sqlpool/) | The pool to take connections from. |


**Returns:**

[SqlRunner](https://imqueue.org/api/pg-prisma/latest/pg-prisma.sqlrunner/)

The pair.

## Remarks

A transaction is one connection, so a statement run on the pool while one is open is not in it — it commits on its own, and the rollback the caller is relying on leaves it behind. Prisma 7 solved this by handing a `tx` client to the callback and asking every write to take it as an argument, which meant threading it through everything the callback reaches.

Here the connection travels in `AsyncLocalStorage` instead: `query` uses the open transaction when there is one and the pool otherwise, so the call sites do not change and cannot get it wrong. Nesting joins the outer transaction rather than opening a second one, which is what a caller composing two operations means by it.

## Example


```typescript
const { query, transaction } = sqlRunner(pool);

await transaction(async () => {
    await query('SET LOCAL lock_timeout = $1', ['5s']);
    await write();
});
```