## Context
Addresses a UX confusion where users are unsure of which schema to
install database extensions in. Am opting to show a "Default" badge on
the extensions schema just to lower the cognitive load for this step if
the extension doesn't have a specific schema it needs to be installed in
<img width="416" height="322" alt="image"
src="https://github.com/user-attachments/assets/b938afdb-31d7-4e9f-a065-7b3b185ac8e1"
/>
If the extension has a recommended schema, we'll show a badge as well
(Related [PR](https://github.com/supabase/supabase/pull/40968))
<img width="429" height="300" alt="image"
src="https://github.com/user-attachments/assets/cf42bce3-a99c-4877-9d16-9f2013b91e16"
/>
Otherwise, if there's a fixed schema, then no badge
<img width="427" height="283" alt="image"
src="https://github.com/user-attachments/assets/608c0c4f-ea8e-4462-ad66-9e3b3bb43265"
/>
## Other changes
- Refactored `EnableExtensionModal` to use react hook form + Dialog
component
- Refactored checking of default schema to use React Query
## To test
- [ ] Verify the UI changes
- [ ] Verify that you can still enable / disable extensions - and ensure
that they're being installed in the right schemas
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Enhanced extension enable dialog with form-driven schema selection,
read-only default-schema display, and "create custom schema" flow
* "Recommended" and "Default" badges next to schema choices;
platform-specific warnings and callouts
* Fetches and surfaces extension default/recommended schema to guide
selection
* **Refactor**
* Dialog-based UI with integrated form validation and improved enable
workflow
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <alaister@users.noreply.github.com>
* fix(studio): check job_run_details size in cron display
When cron.job_run_details grows too large (200k+ rows), loading the
cron jobs overview can timeout and affect other queries by pulling
excessive data into shared buffers.
This change:
- Estimates table size using pg_stat before fetching cron jobs data
- Shows a cleanup notice when the table exceeds the threshold
- Provides batched deletion using ctid ranges to avoid buffer pollution
- Allows scheduling an automated daily cleanup cron job
- Handles timeout errors gracefully with a "suspected overflow" state
The useCronJobsData hook now returns a discriminated union status that
tracks loading, estimate-error, overflow-confirmed, overflow-suspected,
and ready states, allowing the UI to respond appropriately to each case.
* fix(studio): use index when querying cron.job_run_details
cron.job_run_details is only indexed by runid, not by start_time. Change
the query to use the runid index (which gives the same result, since
runid is auto-incrementing).
The global storage size validation depends on an unpaginated buckets
query to determine whether it is lower than any individual bucket's
cutoff. This causes a problem for users with tens of thousands of
buckets.
There's a bit of a UX/performance problem here, because in order to
determine whether any bucket's `file_size_limit` exceeds the global
setting, we need to get the max `file_size_limit` of `storage.buckets`
-- however, that column is not indexed.
My workaround is:
- Below a certain threshold (10,000) buckets, the query for max
`file_size_limit` is automatically run on form submit.
- Above that threshold, the user must confirm whether they want to run
the query. They're still allowed to change the storage config without
running it -- this does open a loophole where they can have a global
storage setting lower than an individual bucket's file size limit, but
though this is a potentially confusing situation, it's not strictly an
error.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
