---
id: generated-code
title: Generated code
sidebar_label: Generated code
---

One output file, written where `output` in the config points, containing four
things per query.

```typescript
// Code generated by pg-describe-gen. DO NOT EDIT.

import type { ClientBase } from 'pg';

// ------------------------------------------------------------------------
// ListRecentOrders  (queries/orders.sql:6)
// ------------------------------------------------------------------------

export interface ListRecentOrdersParams {
  p1: Date
}

export interface ListRecentOrdersRow {
  id: string            // orders.id
  placed_at: Date       // orders.placed_at
  total: string         // orders.total
  note: string | null   // orders.note
  email: string | null  // customers.email
  vip: boolean | null   // customers.vip
}

export const listRecentOrdersSql = `SELECT o.id, o.placed_at, o.total, o.note, c.email, c.vip
FROM orders o
LEFT JOIN customers c ON c.id = o.customer_id
WHERE o.placed_at >= $1
ORDER BY o.placed_at DESC`;

/**
 * Orders with their customer, if any.
 *
 * @see {@link listRecentOrdersSql} — defined in queries/orders.sql
 */
export async function listRecentOrders(
  client: ClientBase,
  params: ListRecentOrdersParams,
): Promise<ListRecentOrdersRow[]> {
  const result = await client.query<ListRecentOrdersRow>(listRecentOrdersSql, [params.p1]);
  return result.rows;
}
```

**The params interface** names parameters `p1`…`pn`, typed from what the
analyser inferred. Omitted entirely for a query with no parameters, in which case
the generated function takes only a client.

**The row interface** has one field per result column, in select-list order,
with a trailing comment naming the source column when the column has provenance.
Nullability comes from `result_not_null` — see [Nullability](nullability.md).

**The SQL constant** is exported so you can run the query yourself when the
generated function is not the right shape — inside a transaction, with a cursor,
or through a different client.

**The function** takes any node-postgres `ClientBase`: a `Client`, a `Pool`, or
a pooled client checked out for a transaction. It passes parameters positionally
in the right order and returns `result.rows`.

## Statements with no result columns

```typescript
export async function deleteOrdersBefore(
  client: ClientBase,
  params: DeleteOrdersBeforeParams,
): Promise<number> {
  const result = await client.query(deleteOrdersBeforeSql, [params.p1]);
  return result.rowCount ?? 0;
}
```

No row interface, and the affected row count instead of an array. Add
`RETURNING` to the query and it changes shape on the next generate.

## The file is meant to be committed

Commit it and review it in pull requests. It is the record of what the database
said your queries return, which is what makes
[`--check`](cli-configuration.md#checking-in-ci) able to fail a build when the
schema drifts away from it. It is also the readable artefact: the diff on a
migration PR shows exactly which fields changed type or became nullable.

Do not edit it. Regenerate instead — `--check` compares byte for byte.