mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
Closes DOCS-1057 Contributes to DOCS-1052 ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## Problem We have hundreds of MDX lint warnings in our docs going against style best practices. ## Solution Remove and replace in context the following: - PostgreSQL. There was only one. There was concern about exceptions, but I found none. - Just - Quickly - Actually ### What changed Edits follow the [Google developer documentation style guide](https://developers.google.com/style): concise, direct, active voice. The flagged words were removed when the sentence still read well, or replaced when meaning needed to be preserved. ### Common patterns | Flagged word | Approach | Example | |---|---|---| | **just** (filler) | Removed | "you just installed" → "you installed" | | **just** (limiting) | **only** | "just one row" → "only one row" | | **just like** | **like** / **the same as** | "function just like regular users" → "function like regular users" | | **not just** | **not only** | "not just errors" → "not only errors" | | **quickly** (performance) | **efficiently** or removed | "find rows quickly" → "find rows efficiently" | | **quickly** (time) | **soon** / **rapidly** / removed | "expires too quickly" → "expires too soon" | | **actually** (filler) | Removed | "actually execute" → "execute"; "is actually the most common" → "is the most common" | ## Tophatting 1. See the diff. 2. See that content continues to make sense in context. 3. Locally, `cd apps/docs` and run `pnpm run lint:mdx`. 4. Search for "just," "actually," "quickly", and "PostgreSQL" and see there are 0 warnings. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated wording across quickstarts, guides, and troubleshooting articles for grammar, clarity, and consistent step-by-step phrasing. * Clarified key concepts including Row Level Security policy evaluation across Supabase products, deferred foreign key constraint behavior, and when `EXPLAIN ANALYZE` executes queries (and related side effects). * Refined several troubleshooting instructions and added guidance to cap log payload size to reduce billed Logs Ingest volume. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Nik Richers <nrichers@gmail.com> Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
100 lines
4.4 KiB
Plaintext
100 lines
4.4 KiB
Plaintext
---
|
|
id: 'postgres-event-triggers'
|
|
title: 'Event Triggers'
|
|
description: 'Automatically execute SQL on database events.'
|
|
subtitle: 'Automatically execute SQL on database events.'
|
|
---
|
|
|
|
In Postgres, an [event trigger](https://www.postgresql.org/docs/current/event-triggers.html) is similar to a [trigger](/docs/guides/database/postgres/triggers), except that it is triggered by database level events (and is usually reserved for [superusers](/docs/guides/database/postgres/roles-superuser))
|
|
|
|
With our `Supautils` extension (installed automatically for all Supabase projects), the `postgres` user has the ability to create and manage event triggers.
|
|
|
|
Some use cases for event triggers are:
|
|
|
|
- Capturing Data Definition Language (DDL) changes - these are changes to your database schema (though the [pgAudit](/docs/guides/database/extensions/pgaudit) extension provides a more complete solution)
|
|
- Enforcing/monitoring/preventing actions - such as preventing tables from being dropped in Production or enforcing RLS on all new tables
|
|
|
|
The guide covers two example event triggers:
|
|
|
|
1. Preventing accidental dropping of a table
|
|
2. Automatically enabling Row Level Security on new tables in the `public` schema
|
|
|
|
## Creating an event trigger
|
|
|
|
Only the `postgres` user can create event triggers, so make sure you are authenticated as them. As with triggers, event triggers consist of 2 parts
|
|
|
|
1. A [Function](/docs/guides/database/functions) which will be executed when the triggering event occurs
|
|
2. The actual Event Trigger object, with parameters around when the trigger should be run
|
|
|
|
### Example trigger function - prevent dropping tables
|
|
|
|
This example protects any table from being dropped. You can override it by temporarily disabling the event trigger: `ALTER EVENT TRIGGER dont_drop_trigger DISABLE;`
|
|
|
|
```sql
|
|
-- Function
|
|
CREATE OR REPLACE FUNCTION dont_drop_function()
|
|
RETURNS event_trigger LANGUAGE plpgsql AS $$
|
|
DECLARE
|
|
obj record;
|
|
tbl_name text;
|
|
BEGIN
|
|
FOR obj IN SELECT * FROM pg_event_trigger_dropped_objects()
|
|
LOOP
|
|
IF obj.object_type = 'table' THEN
|
|
RAISE EXCEPTION 'ERROR: All tables in this schema are protected and cannot be dropped';
|
|
END IF;
|
|
END LOOP;
|
|
END;
|
|
$$;
|
|
|
|
-- Event trigger
|
|
CREATE EVENT TRIGGER dont_drop_trigger
|
|
ON sql_drop
|
|
EXECUTE FUNCTION dont_drop_function();
|
|
```
|
|
|
|
### Example trigger function - auto enable Row Level Security
|
|
|
|
See how to [auto enable RLS for new tables](/docs/guides/database/postgres/row-level-security#auto-enable-rls-for-new-tables).
|
|
|
|
### Event trigger Functions and firing events
|
|
|
|
Event triggers can be triggered on:
|
|
|
|
- `ddl_command_start` - occurs before a DDL command for almost all objects within a schema
|
|
- `ddl_command_end` - occurs after a DDL command for almost all objects within a schema
|
|
- `sql_drop` - occurs before `ddl_command_end` for any DDL commands that `DROP` a database object (note that altering a table can cause it to be dropped)
|
|
- `table_rewrite` - occurs before a table is rewritten using the `ALTER TABLE` command
|
|
|
|
<Admonition type="caution">
|
|
|
|
Event triggers run for each DDL command specified above and can consume resources which may cause performance issues if not used carefully.
|
|
|
|
</Admonition>
|
|
|
|
Within each event trigger, helper functions exist to view the objects being modified or the command being run. For example, our example calls `pg_event_trigger_dropped_objects()` to view the object(s) being dropped. For a more comprehensive overview of these functions, read the [official event trigger definition documentation](https://www.postgresql.org/docs/current/event-trigger-definition.html)
|
|
|
|
To view the matrix commands that cause an event trigger to fire, read the [official event trigger matrix documentation](https://www.postgresql.org/docs/17/event-trigger-matrix.html)
|
|
|
|
## Disabling an event trigger
|
|
|
|
You can disable an event trigger using the `alter event trigger` command:
|
|
|
|
```sql
|
|
ALTER EVENT TRIGGER dont_drop_trigger DISABLE;
|
|
```
|
|
|
|
## Dropping an event trigger
|
|
|
|
You can delete a trigger using the `drop event trigger` command:
|
|
|
|
```sql
|
|
DROP EVENT TRIGGER dont_drop_trigger;
|
|
```
|
|
|
|
## Resources
|
|
|
|
- Official Postgres Docs: [Event Trigger Behaviours](https://www.postgresql.org/docs/current/event-trigger-definition.html)
|
|
- Official Postgres Docs: [Event Trigger Firing Matrix](https://www.postgresql.org/docs/17/event-trigger-matrix.html)
|
|
- Supabase blog: [Postgres Event Triggers without superuser access](/blog/event-triggers-wo-superuser)
|