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.  ## 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.  ## 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-06 01:45:10 +03:00 · 2026-10-05 15:18:00 -07:00
1 parent a9078612f2
commit 8b148f93c1
@@ -1099,6 +1099,10 @@ export const database: NavMenuConstant = {
          name: 'Managing database functions',
          url: '/guides/database/functions' as `/${string}`,
        },
+        {
+          name: 'Debugging database functions',
+          url: '/guides/database/debugging-functions' as `/${string}`,
+        },
        {
          name: 'Managing database triggers',
          url: '/guides/database/postgres/triggers' as `/${string}`,
@@ -0,0 +1,173 @@
+---
+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();
+```
@@ -344,7 +344,7 @@ To prevent PGAudit from monitoring the problematic roles, you'll want to change

 ### Using PGAudit to debug database functions

-Technically yes, but it is not the best approach. It is better to check out our [function debugging guide](/docs/guides/database/functions#general-logging) instead.
+Technically yes, but it is not the best approach. It is better to check out our [function debugging guide](/docs/guides/database/debugging-functions#general-logging) instead.

 ### Downloading database logs

@@ -387,6 +387,6 @@ PGAudit's [official documentation](https://www.pgaudit.org) focuses on system an
 ## Resources

 - [Official `PGAudit` documentation](https://www.pgaudit.org)
- [Database Function Logging](/docs/guides/database/functions#general-logging)
+- [Database Function Logging](/docs/guides/database/debugging-functions#general-logging)
 - [Supabase Logging](/docs/guides/observability/logs)
 - [Self-Hosting Logs](/docs/reference/self-hosting-analytics/introduction)
@@ -1,6 +1,6 @@
 ---
 id: 'functions'
-title: 'Database Functions'
+title: 'Database functions'
 description: 'Creating and using Postgres functions.'
 video: 'https://www.youtube.com/v/MJZCCpCYEqk'
 ---
@@ -8,11 +8,24 @@ video: 'https://www.youtube.com/v/MJZCCpCYEqk'
 Postgres has built-in support for [SQL functions](https://www.postgresql.org/docs/current/sql-createfunction.html).
 These functions live inside your database, and you can call them from your app with [`rpc()`](../../reference/javascript/rpc).

+- [Database functions vs Edge Functions](#database-functions-vs-edge-functions) compares the two. Start here if you aren't sure which one fits.
+- [Create a database function](#create-a-database-function) has the steps, from a one-line function to one that takes parameters.
+- [Secure a database function](#secure-a-database-function) covers which user the function runs as and who can call it.
+- [Debugging database functions](/docs/guides/database/debugging-functions) covers logging and error handling.
+
 ## Quick demo

 <YouTube id="MJZCCpCYEqk" title="Creating and calling Postgres functions" />

-## Getting started
+## Database functions vs Edge Functions
+
+For data-intensive operations, use database functions. They run inside your database, and you can call them remotely with the [REST and GraphQL API](../api).
+
+For use cases that need low latency, use [Edge Functions](../../guides/functions). They're globally distributed and you write them in TypeScript.
+
+## Create a database function
+
+### Getting started

 Create a database function from the Dashboard, or write the SQL yourself against a
 [direct connection](../../guides/database/connecting-to-postgres).
@@ -24,7 +37,7 @@ To use the Dashboard:
 3. Enter the SQL that creates or replaces your database function.
 4. Click **Run**. You can also press `cmd+enter` or `ctrl+enter`.

-## Basic functions [#simple-functions]
+### Basic functions [#simple-functions]

 Create a basic database function that returns the string "hello world".

@@ -141,7 +154,7 @@ Reference: [`Rpc()`](../../reference/csharp/rpc)
 </$Show>
 </Tabs>

-## Returning data sets
+### Returning data sets

 A database function can also return a data set from a [table](../../guides/database/tables) or a view.

@@ -156,7 +169,7 @@ For example, take a database holding some Star Wars data:
 >
 <TabPanel id="data" label="Data">

-### Planets
+#### Planets

 ```
 | id  | name     |
@@ -166,7 +179,7 @@ For example, take a database holding some Star Wars data:
 | 3   | Kashyyyk |
 ```

-### People
+#### People

 ```
 | id  | name             | planet_id |
@@ -291,7 +304,7 @@ data = supabase.rpc('get_planets').eq('id', 1).execute()
 </$Show>
 </Tabs>

-## Passing parameters
+### Passing parameters

 Create a function that inserts a new planet into the `planets` table and returns the new ID. This function uses the `plpgsql` language.

@@ -408,13 +421,7 @@ await supabase.Rpc("add_planet", new Dictionary<string, object> { { "name", "Jak
 </$Show>
 </Tabs>

-## Suggestions
-
-### Database Functions vs Edge Functions
-
-For data-intensive operations, use database functions. They run inside your database, and you can call them remotely with the [REST and GraphQL API](../api).
-
-For use cases that need low latency, use [Edge Functions](../../guides/functions). They're globally distributed and you write them in TypeScript.
+## Secure a database function

 ### Security `definer` vs `invoker`

@@ -469,174 +476,6 @@ By default, any role can run a database function. You can restrict execution in
    grant execute on function public.hello_world to authenticated;
    ```

-### Debugging functions
-
-Add logs to help you debug a function. Logs matter most in a complex function.
-
-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();
-```
-
 ## Resources

 - Official Client libraries: [JavaScript](../../reference/javascript/rpc) and [Flutter](../../reference/dart/rpc)
@@ -644,16 +483,14 @@ select advanced_example();
 - Postgres Official Docs: [Chapter 9. Functions and Operators](https://www.postgresql.org/docs/current/functions.html)
 - Postgres Reference: [CREATE FUNCTION](https://www.postgresql.org/docs/9.1/sql-createfunction.html)

-## Deep dive
-
-### Create Database Functions
+### Create a database function in the Dashboard

 <YouTube id="MJZCCpCYEqk" title="Creating a Postgres function in the dashboard" />

-### Call Database Functions using JavaScript
+### Call a database function from JavaScript

 <YouTube id="I6nnp9AINJk" title="Calling a Postgres function from JavaScript" />

-### Using Database Functions to call an external API
+### Call an external API from a database function

 <YouTube id="rARgrELRCwY" title="Calling an external API from a Postgres function" />
@@ -823,16 +823,16 @@ Determines what _query generated_ logs (not background or networking logs) are r

 As an example of how `log_min_messages` works, if the setting were changed to `error`, Postgres would stop recording logs with the severity levels `warning`, `notice`, `info`, and `debug1 ... debug5` events. However, it would continue recording all `error`, `log`, `fatal`, and `panic` occurrences.

-| Severity              | Description                                                                                                                                                                                                                                                          | Example log                                                                                                                                                                          |
-| :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **debug1 ... debug5** | Successively detailed debugging and server info, predominantly used by Postgres developers and extension maintainers.                                                                                                                                                | `DEBUG1: rehashing catalog cache id 6...`                                                                                                                                            |
-| **info**              | Information explicitly requested by the user during an operation.                                                                                                                                                                                                    | `INFO: analyzing "public.example..."` <br/><br/> Example returned by the [`analyze verbose`](https://www.postgresql.org/docs/current/sql-analyze.html) command                       |
-| **notice**            | Helpful, non-essential information about automatic background actions.                                                                                                                                                                                               | `NOTICE: table "old_logs" does not exist, skipping` <br/><br/> Example returned by the [`drop table if exists`](https://www.postgresql.org/docs/current/sql-droptable.html) commands |
-| **warning**           | A query completed, but skipped requested actions.                                                                                                                                                                                                                    | `WARNING: no privileges were granted for "some_user"` <br/><br/> Example returned by the [`grant`](https://www.postgresql.org/docs/current/sql-grant.html) command                   |
-| **error**             | A specific query failed, but the overall database connection remains alive.                                                                                                                                                                                          | `ERROR: duplicate key value violates unique constraint "example_pkey"`                                                                                                               |
-| **log**               | Operational events. Usually generated by [background activity log settings](/docs/guides/database/postgres/postgres-log-config#background-activity) or by [database functions](/docs/guides/database/functions?queryGroups=language&language=js#debugging-functions) | `LOG: connection received...`                                                                                                                                                        |
-| **fatal**             | An error that causes a database connection to abruptly terminate.                                                                                                                                                                                                    | `FATAL: terminating connection due to administrator command`                                                                                                                         |
-| **panic**             | A critical, system-wide failure that forces the database to shut down and crash-recover.                                                                                                                                                                             | `PANIC: could not locate a valid checkpoint record at 0/61013608`                                                                                                                    |
+| Severity              | Description                                                                                                                                                                                                               | Example log                                                                                                                                                                          |
+| :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **debug1 ... debug5** | Successively detailed debugging and server info, predominantly used by Postgres developers and extension maintainers.                                                                                                     | `DEBUG1: rehashing catalog cache id 6...`                                                                                                                                            |
+| **info**              | Information explicitly requested by the user during an operation.                                                                                                                                                         | `INFO: analyzing "public.example..."` <br/><br/> Example returned by the [`analyze verbose`](https://www.postgresql.org/docs/current/sql-analyze.html) command                       |
+| **notice**            | Helpful, non-essential information about automatic background actions.                                                                                                                                                    | `NOTICE: table "old_logs" does not exist, skipping` <br/><br/> Example returned by the [`drop table if exists`](https://www.postgresql.org/docs/current/sql-droptable.html) commands |
+| **warning**           | A query completed, but skipped requested actions.                                                                                                                                                                         | `WARNING: no privileges were granted for "some_user"` <br/><br/> Example returned by the [`grant`](https://www.postgresql.org/docs/current/sql-grant.html) command                   |
+| **error**             | A specific query failed, but the overall database connection remains alive.                                                                                                                                               | `ERROR: duplicate key value violates unique constraint "example_pkey"`                                                                                                               |
+| **log**               | Operational events. Usually generated by [background activity log settings](/docs/guides/database/postgres/postgres-log-config#background-activity) or by [database functions](/docs/guides/database/debugging-functions) | `LOG: connection received...`                                                                                                                                                        |
+| **fatal**             | An error that causes a database connection to abruptly terminate.                                                                                                                                                         | `FATAL: terminating connection due to administrator command`                                                                                                                         |
+| **panic**             | A critical, system-wide failure that forces the database to shut down and crash-recover.                                                                                                                                  | `PANIC: could not locate a valid checkpoint record at 0/61013608`                                                                                                                    |

 <Admonition type="note">

@@ -931,5 +931,5 @@ Review the [pgAudit docs](/docs/guides/database/extensions/pgaudit) for more con
 ## Resources

 - [Advanced Log Filtering](/docs/guides/observability/advanced-log-filtering)
- [Database Function Logging](/docs/guides/database/functions#general-logging)
+- [Database Function Logging](/docs/guides/database/debugging-functions#general-logging)
 - [Supabase Logging](/docs/guides/observability/logs)
@@ -369,7 +369,7 @@ By default, only failed queries are logged. The [PGAudit extension](/docs/guides

 #### Logging within database functions

-To track or debug functions, logging can be configured by following the [function debugging guide](/docs/guides/database/functions#general-logging)
+To track or debug functions, logging can be configured by following the [function debugging guide](/docs/guides/database/debugging-functions#general-logging)

 ## Frequently Asked Questions

@@ -389,7 +389,7 @@ To see the default types of events that are logged, you can check this [guide](h

 - [Regex for filtering logs](https://github.com/orgs/supabase/discussions/22640)
 - [Debugging with the DB API logs](https://github.com/orgs/supabase/discussions/22849)
- [Debugging Database Functions](/docs/guides/database/functions#debugging-functions)
+- [Debugging Database Functions](/docs/guides/database/debugging-functions)
 - [pg_audit](/docs/guides/database/extensions/pgaudit)
 - [Supabase Logging](/docs/guides/observability/logs)
 - [Self-Hosting Logs](/docs/reference/self-hosting-analytics/introduction)
@@ -117,4 +117,4 @@ We support PGAudit extension, which extends Postgres’s built-in logging capabi
 For detailed configuration instructions and logging options, refer to the complete documentation: [PGAudit Configuration Guide](/docs/guides/database/extensions/pgaudit?queryGroups=database-method&database-method=dashboard#configure-the-extension)

 **c. Debugging Functions**
-For more information on how to debug functions in Supabase, refer to the official guide: [Debugging Functions](/docs/guides/database/functions?queryGroups=language&language=js#debugging-functions).
+For more information on how to debug functions in Supabase, refer to the official guide: [Debugging Functions](/docs/guides/database/debugging-functions).