Files
supabase/apps/docs/content/guides/database/debugging-functions.mdx
T
Miranda Limonczenko 8b148f93c1 docs(database): regroup the database functions guide and split out debugging (#50821)
Part 2 of 4 in stack #50823. This PR carries **structure only**: moves,
regrouping, and the connective text the new shape needs. Reworded prose
already landed in #50820.

## Problem

This PR is running a structure edit.

A reader arrives from search and has to find one thing. The guide gave
them eight top-level headings, no grouping, and no opening outline. The
style guide caps a group at 5 ± 1.

Four of those headings are the action path: Getting started, Basic
functions, Returning data sets, and Passing parameters. Nothing marked
them as one sequence.

`Suggestions` held four unrelated things: an Edge Functions comparison,
two security topics, and a three-part debugging reference. The heading
names nothing the reader is doing.

Debugging was the largest thing on the page. It sat at H3 with three H4
children, and it shared only the word "function" with the rest of the
guide.

## Solution

- **Groups the four procedures** under `Create a database function`, so
the action path is one unbroken sequence.
- **Moves the Edge Functions comparison ahead of the procedures.** A
reader choosing between the two needs it before the steps, not after
them.
- **Groups the two security sections** under `Secure a database
function`.
- **Splits debugging onto its own page**,
`guides/database/debugging-functions`. It is registered in the Database
sidebar and cross-referenced from the guide.
- **Folds `Deep dive` into `Resources`.** Two trailing headings did one
job.
- **Adds an opening outline** linking each group and saying when to use
it.
- **Renames the frontmatter title** to sentence case, `Database
functions`.

## Manual testing

1. Open the [guide on the deploy
preview](https://docs-git-docs-functions-structure-supabase.vercel.app/docs/guides/database/functions).
Five top-level headings, with the opening outline linking each group.
2. Open the [new debugging
page](https://docs-git-docs-functions-structure-supabase.vercel.app/docs/guides/database/debugging-functions).
It appears in the Database sidebar under Managing database functions.
3. Follow a repointed link. Open [Postgres log
config](https://docs-git-docs-functions-structure-supabase.vercel.app/docs/guides/database/postgres/postgres-log-config)
and click Database Function Logging. It lands on the new page at General
logging.
4. Run `pnpm build:guides-markdown` from `apps/docs`. Both pages appear
under `public/markdown/guides/database/`. Discard the `manifest.json`
change.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Added a guide to debugging Postgres database functions, with examples
for logging, error handling, and inspecting query results.
* Added the guide to Database navigation and updated related resources
to link to it.
* Reorganized the database functions guide to clarify function creation,
security, and privileges.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## Preview links

| Site | Live | Preview | Search for |
| --- | --- | --- | --- |
| Docs |
[/docs/guides/database/functions](https://supabase.com/docs/guides/database/functions)
|
[/docs/guides/database/functions](https://docs-git-docs-functions-structure-supabase.vercel.app/docs/guides/database/functions)
| `Secure a database function` |
| Docs | New page, 404 in production |
[/docs/guides/database/debugging-functions](https://docs-git-docs-functions-structure-supabase.vercel.app/docs/guides/database/debugging-functions)
| `Debugging database functions` |
| Docs |
[/docs/guides/database/postgres/postgres-log-config](https://supabase.com/docs/guides/database/postgres/postgres-log-config)
|
[/docs/guides/database/postgres/postgres-log-config](https://docs-git-docs-functions-structure-supabase.vercel.app/docs/guides/database/postgres/postgres-log-config)
| `Database Function Logging` |

## Review instructions

This PR moves content. The risk is a broken link, not bad prose.

1. Open the preview of the guide. Count the top-level headings in the
right-hand outline. There are five, down from eight.
2. Read the four bullets at the top of the page. Each links to a group,
and each says when to use it. Click all four and confirm each lands on
its section.
3. Open the new debugging page from the second row. Confirm it appears
in the left sidebar under **Managing database functions**.
4. **Check the three locked anchors.** Append each to the preview guide
URL and confirm the page jumps: `#quick-demo`,
`#security-definer-vs-invoker`. Then append `#general-logging` to the
**debugging page** URL. Four other pages link to these.
5. Open the Postgres log config preview from the third row. Find
**Database Function Logging** in the Resources list and click it. It
lands on the new debugging page, not on a dead anchor.
6. Compare the prose against the live page. **No sentence should have
changed** beyond the new opening outline and the cross-reference to the
debugging page.

**If you only have two minutes:** do steps 4 and 5. A moved section that
leaves a dead anchor is the failure this PR could cause.

**A note on running SQL from this page.** Don't hand-paste from the
rendered page. Blocks are split across tabs, and the Data tab in
Returning data sets holds markdown tables that look pasteable but are
not SQL. Use the `.md` export of the page, which flattens every tab in
page order. #50822 has a copy-paste command for this.
2026-10-05 15:18:00 -07:00

174 lines
4.2 KiB
Plaintext

---
id: 'debugging-functions'
title: 'Debugging database functions'
description: 'Logging and error handling inside Postgres functions.'
---
Add logs and error handling to a database function so you can see what it does at runtime. Logs matter most in a complex function.
For how to write and call a function, see [Database functions](/docs/guides/database/functions).
Good targets to log include:
- Values of (non-sensitive) variables
- Returned results from queries
## General logging
Use the `raise` keyword to write custom logs to the [Postgres logs](/dashboard/project/_/logs/postgres-logs) in the Dashboard. Three severity levels appear by default:
- `log`
- `warning`
- `exception` (error level)
```sql
create function logging_example(
log_message text,
warning_message text,
error_message text
)
returns void
language plpgsql
as $$
begin
raise log 'logging message: %', log_message;
raise warning 'logging warning: %', warning_message;
-- immediately ends function and reverts transaction
raise exception 'logging error: %', error_message;
end;
$$;
select logging_example('LOGGED MESSAGE', 'WARNING MESSAGE', 'ERROR MESSAGE');
```
## Error handling
You can create custom errors with the `raise exception` keywords.
A common pattern is to throw an error when a variable doesn't meet a condition:
```sql
create or replace function error_if_null(some_val text)
returns text
language plpgsql
as $$
begin
-- error if some_val is null
if some_val is null then
raise exception 'some_val should not be NULL';
end if;
-- return some_val if it is not null
return some_val;
end;
$$;
select error_if_null(null);
```
Value checking is common, so Postgres provides the `assert` keyword as a shorthand. It takes the following format:
```sql
-- throw error when condition is false
assert <some condition>, 'message';
```
For example:
```sql
create function assert_example(name text)
returns uuid
language plpgsql
as $$
declare
student_id uuid;
begin
-- save a user's id into the user_id variable
select
id into student_id
from attendance_table
where student = name;
-- throw an error if the student_id is null
assert student_id is not null, 'assert_example() ERROR: student not found';
-- otherwise, return the user's id
return student_id;
end;
$$;
select assert_example('Harry Potter');
```
You can also capture and modify an error message with the `exception` keyword:
```sql
create function error_example()
returns void
language plpgsql
as $$
begin
-- fails: cannot read from nonexistent table
select * from table_that_does_not_exist;
exception
when others then
raise exception 'An error occurred in function <function name>: %', sqlerrm;
end;
$$;
```
## Advanced logging
For a more complex function, or for harder debugging, log the following:
- Formatted variables
- Individual rows
- Start and end of function calls
```sql
create or replace function advanced_example(num int default 10)
returns text
language plpgsql
as $$
declare
var1 int := 20;
var2 text;
begin
-- Logging start of function
raise log 'logging start of function call: (%)', (select now());
-- Logging a variable from a SELECT query
select
col_1 into var1
from some_table
limit 1;
raise log 'logging a variable (%)', var1;
-- It is also possible to avoid using variables, by returning the values of your query to the log
raise log 'logging a query with a single return value(%)', (select col_1 from some_table limit 1);
-- If necessary, you can even log an entire row as JSON
raise log 'logging an entire row as JSON (%)', (select to_jsonb(some_table.*) from some_table limit 1);
-- When using INSERT or UPDATE, the new value(s) can be returned
-- into a variable.
-- When using DELETE, the deleted value(s) can be returned.
-- All three operations use "RETURNING value(s) INTO variable(s)" syntax
insert into some_table (col_2)
values ('new val')
returning col_2 into var2;
raise log 'logging a value from an INSERT (%)', var2;
return var1 || ',' || var2;
exception
-- Handle exceptions here if needed
when others then
raise exception 'An error occurred in function <advanced_example>: %', sqlerrm;
end;
$$;
select advanced_example();
```