mirror of
https://github.com/supabase/supabase.git
synced 2026-07-02 00:54:25 +08:00
32 lines
1.4 KiB
Plaintext
32 lines
1.4 KiB
Plaintext
<Admonition type="caution">
|
|
|
|
The `pgrst.db_pre_request` configuration only works with the **Data API** (PostgREST). It does not work with Realtime, Storage, or other Supabase products.
|
|
|
|
If you're using `db_pre_request` to call a function (like `set_information()`) that sets up context or performs checks on every request, and you need similar behavior for other Supabase products, you must call the function directly in your Row Level Security (RLS) policies instead.
|
|
|
|
**Example:**
|
|
|
|
If you have a `db_pre_request` function that calls `set_information()` that returns `true` to set up context or perform checks, and you have an RLS policy like:
|
|
|
|
```sql
|
|
create policy "Individuals can view their own todos."
|
|
on todos for select
|
|
using ( (select auth.uid()) = user_id );
|
|
```
|
|
|
|
To achieve the same behavior with other Supabase products, you need to call the function directly in your RLS policy:
|
|
|
|
```sql
|
|
create policy "Individuals can view their own todos."
|
|
on todos for select
|
|
using ( set_information() AND (select auth.uid()) = user_id );
|
|
```
|
|
|
|
This ensures the function is called when evaluating RLS policies for all products, not just Data API requests.
|
|
|
|
**Performance consideration:**
|
|
|
|
Be aware that calling functions directly in RLS policies can impact database performance, as the function is evaluated for each row when the policy is checked. Consider optimizing your function or using caching strategies if performance becomes an issue.
|
|
|
|
</Admonition>
|