## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Performance improvement
## What is the current behavior?
The column privileges page in Studio only ever renders one table, but
the underlying query still `aclexplode`s every column in the whole
schema and filters the result client-side.
## What is the new behavior?
Adds a scoped SQL path that prunes `pg_class`/`pg_namespace` to the
requested schema+table before exploding ACLs, gated behind the
`pgMetaScopedIntrospection` flag, with a plan-guard test asserting
`pg_class`/`pg_attribute` stay index-driven. Studio's query hook and
cache keys now thread the selected table through so column-privilege
invalidation and cold-load races are scoped correctly, and the page
fetches per-table instead of per-schema.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* Column privileges are now scoped to the selected schema and table for
more accurate results.
* Changing schemas automatically updates the table selection and
refreshes the displayed privileges.
* Privilege updates now refresh only the relevant schema, table, and
column data.
* Loading states are handled more accurately when no table is selected.
* **Bug Fixes**
* Improved consistency between scoped and unscoped column privilege
results, including table-, column-, and grant-option privileges.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
The dashboard has an RQ hook that fetches all table privileges in the
database `useTablePrivilegesQuery`
[here](https://github.com/supabase/supabase/blob/master/apps/studio/data/privileges/table-privileges-query.ts#L21)
which can potentially be a resource heavy query on the database,
especially if the database has a large number of relations.
A recent UI that was added `ProjectNeedsSecuring` uses that query, and
has become a common entry point for all projects as it's rendered when
the user lands on the project's home page, and the project has tables
with RLS issues, in which case if the project has a large number of
tables, the database will face run into resource issues, resulting in
statement timeouts.
## Changes involved
Opting to pass in `includedSchemas` parameter wherever we're calling
`useTablePrivilegesQuery`, which includes:
- `ProjectNeedsSecuring`
- `QueueSettings`
- `column-privileges`
In which we'll hence only fetch the table privileges for the provided
schemas only (rather than the whole DB)
Also did a similar fix for `useColumnPrivilegesQuery` as well as it
likely runs into the same problem
## To test
- [ ] Verify that those 3 UIs are still working as expected (should not
have any visual changes)
- [ ] Verify in the network tab that table / column privileges are now
filtered to the schema provided, rather than fetching for all schemas in
the DB
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved permission-save failure messaging by generating clearer toast
errors from unexpected failures.
* Prevented privilege-related UI from loading until required
configuration is successfully retrieved.
* **Performance**
* Faster, more targeted privilege loading by scoping both table and
column privilege queries to the selected/relevant schema(s), reducing
unnecessary client-side filtering.
* Switched privilege retrieval to schema-aware database metadata queries
for more efficient results.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
The autogenerated Data API docs listed every table and database function
from the PostgREST OpenAPI spec, even ones that aren't actually
accessible via the Data API (i.e. with grants revoked). This filters the
docs down to only the entities that are exposed, and surfaces a count of
the excluded ones with a link to enable them.
This applies to **both** autogenerated docs surfaces:
- the **API Docs side panel** (the slide-over opened from the API docs
button), and
- the **full-page Data API docs** at `/integrations/data_api/docs`.
<img width="259" height="272" alt="Screenshot 2026-06-01 at 5 48 21 PM"
src="https://github.com/user-attachments/assets/d2af86f2-5436-4e94-8295-83ecc74a77d9"
/>
**Changed:**
- Both docs UIs now only list tables and functions that have Data API
access (any `anon`/`authenticated`/`service_role` grant). Fully-revoked
entities are hidden.
- Side panel: both the sidebar list and the drilled-in resource picker
are filtered.
- Full page: the menu's Tables/Functions groups are filtered, with a
footer note under each.
**Added:**
- A footer under each list — "N table(s)/function(s) not exposed via
**Data API**" — linking to Data API settings
(`/integrations/data_api/settings`) so the entity can be granted access.
- One-shot `useExposedTablesQuery` / `useExposedFunctionsQuery` hooks
reusing the same granted/custom/revoked SQL as the Data API settings
page (no new SQL).
- Pure, unit-tested `partitionExposedDocsEntities()` helper (fails open
if grant status hasn't loaded / errors, so docs are never blanked).
- Optional `footer` slot on `ProductMenuGroup` (rendered by `DocsMenu`)
so the full-page menu can show the not-exposed note under a group.
**Note on the "all" queries:** the new `useExposedTablesQuery` /
`useExposedFunctionsQuery` fetch the full grant-status list in a single
request (rather than paginating like the Data API settings page does).
This is deliberate — the docs sections aren't paginated and render every
entity from the OpenAPI spec at once, so we need the complete status set
to cross-reference against. Ideally we'd refactor the docs to be
paginated in future, at which point these queries should move to a
paginated approach too; until then, the one-shot "all" fetch is what
matches the current (unpaginated) docs behavior.
## To test
- On a project, revoke a `public` table's Data API access (Data API
settings → uncheck it)
- Open the **full-page** docs at `/integrations/data_api/docs`: the
table should no longer appear under Tables and Views, and you should see
"1 table not exposed via Data API" under that menu group
- Open the **API Docs side panel** and expand Tables and Views: same
behavior
- Click the "Data API" link → goes to Data API settings (closes the side
panel if open)
- Same for a database function under Functions
- Tables/functions that are still granted (or have custom/partial
grants) should remain visible
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Data API docs now reflect actual exposure: tables/functions not
exposed by permissions are hidden and counted.
* Sections display footer indicators with counts of hidden entities and
links to Data API settings.
* Navigation lists and docs menu updated to show only exposed entities
and the new "not exposed" cues.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Adds a new toggle in:
<img width="1161" height="356" alt="Screenshot 2026-03-10 at 17 17 06"
src="https://github.com/user-attachments/assets/b09ac1aa-a8f5-4fb4-8771-f113b140eac8"
/>
Other changes:
- form submissions with no table/function changes were failing because
an empty string got passed to executeSql. Added an early return when
there's nothing to execute
To test:
- Ensure the form is still in working order
- Create some tables and functions with the toggle on add off and make
sure your selected default applies
**Changes:**
- Add function exposure controls to Data API settings
- Adds a per-function GRANT/REVOKE UI to the Data API settings page,
alongside the existing table selector.
- Empty state: shows "No tables/functions available" instead of "0 of 0
X exposed" when there's nothing to show
- Renamed update-exposed-tables-mutation →
update-exposed-entities-mutation to handle both tables and functions in
one save
**Decisions of note:**
- Functions are grouped by schema.name across overloads — toggling one
entry grants/revokes `EXECUTE` on all overloads
- Only normal and window functions are shown (`prokind in ('f', 'w')`) —
triggers and aggregates are excluded
---
**To test:**
- Table and schema selectors still works end-to-end
- Toggling a function and saving updates the count label and applies the
grant (check via SQL Editor: select * from
information_schema.role_routine_grants where routine_schema = 'public')
- Functions in unexposed schemas are dimmed and unclickable
- With no functions in the selected schemas, the selector label reads
"No functions available" and the dropdown shows the same
Adds a feature flagged exposed tables config to postgrest settings:
<img width="1158" height="589" alt="Screenshot 2026-03-02 at 17 04 13"
src="https://github.com/user-attachments/assets/8fa8ab81-0bfa-4781-83bc-80ac52e180f8"
/>
To test:
- make sure the existing (feature flag off) settings work as expected
- make sure exposing and removing schemas works in the new mode
- make sure exposing and removing tables works in the new mode
- ideally try with a lot of tables to check search and infinite scroll
work as expected
- try exposing a schema without any tables (like `graphql_public`) and
make sure it doesn't get removed randomly when editing tables
- try with a table with custom permissions (for example `REVOKE SELECT
ON public.posts FROM anon;`) and make sure the user is informed with the
tooltip
---------
Co-authored-by: Nick Babadzhanian <33933459+pgnickb@users.noreply.github.com>
* feat(studio): show icon on tables exposed by data api
Show an icon in the Table Editor for tables that are exposed via the
Data API.
* refactor(studio): move table api access query up to parent
* fix(studio): invalidate table privileges query on table create
* fix(studio): make RLS disabled warning on table editor more obvious
Change from warning -> danger
* Only show add foreign key in side panel if isSuccess
* chore(studio): put data api exposed badge behind feature flag
Only show badge for now if flag `dataApiExposedBadge` is enabled.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* add privileges page
* fix
* fix: could have both global and column-specific privileges + is global per privilege
* Trigger Build
* load permissions data for current table only
* fix style for light theme
* add a guide to Privileges
* Update apps/docs/pages/guides/auth/column-level-security.mdx
Co-authored-by: Greg Richardson <greg.nmr@gmail.com>
* Update apps/docs/pages/guides/auth/column-level-security.mdx
Co-authored-by: Greg Richardson <greg.nmr@gmail.com>
* Update doc
* Update docs
* progress moving privileges to pg-meta
* split up column privileges and table privileges
* adds loading state to toggles
* Add feature flag, move from auth section to database section
* Cleanup
* Update meta store table lists, add header warnings, update docs
* Add alert if any columns have privilages
* Spelling
* fix api.d.ts
* fix link
* move to auth pages
* only show editable schemas
* limit roles
* auto select first table
* remove roles meta store
* inline toggling
* apply privileges all at once
* add preview and use new switch component
* fix spelling
* handle long column names
* warn users about losing changes when changing schemas/tables
* remove strange docs link
* fix feature preview after reload
* use shadcn select
* Update select.tsx
* Minor UX fixes
* Update toast
* Update feature preview image for cls
* update cls warnings
* update warnings
* fix toast message
* Add migration alert to preview page
* Add link to CLS from feature preview, and add empty state on CLS page if feature preview is not enabled
* Shift local storage keys hard code to lib/constants
---------
Co-authored-by: Copple <10214025+kiwicopple@users.noreply.github.com>
Co-authored-by: Greg Richardson <greg.nmr@gmail.com>
Co-authored-by: Terry Sutton <saltcod@gmail.com>
Co-authored-by: Alaister Young <a@alaisteryoung.com>
Co-authored-by: Jonathan Summers-Muir <MildTomato@users.noreply.github.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>