## Context
Related to FE-2557
Part of shifting manually written dashboard queries into
packages/pg-meta where
- pg-meta can be code owners of
- we can write tests for the queries
This PR just shifts all the `.sql.ts` files that we previously created
into packages/pg-meta
There's still other areas where we need to shift over as well which I'll
address in subsequent PRs
## Notable changes
- `getTableRowsCountSql` -> Opted to shift `formatFilterValue` logic out
before calling this method (ref `table-rows-count-query`)
- `getDeleteOldCronJobRunDetailsByCtidSql` -> Opted to shift
`validatePageNumber` logic out before calling this method (ref
`CronJobsTab.useCleanupActions`)
## Context
Related to Dashboard Scalability, specifically having Postgres team as
CODEOWNERS for dashboard queries
This is just a clean up as we're currently piling manual queries into
one folder under `data/sql/queries`, whereas I reckon it'll be better
for each query to sit within their RQ folder for better context.
Am opting the naming format for files housing queries to be `*.sql.ts`,
and also updating CODEOWNERS to reflect as such
Next step will also be to shift all the dashboard queries within pg-meta
into studio itself as requested by the pg-meta team
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Consolidated and reorganized internal module structure for the data
layer to improve maintainability and reduce redundancy.
* Streamlined import paths across components to align with new
consolidated module organization.
* **Chores**
* Updated code ownership patterns to reflect reorganized file structure.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
## 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>
Joshen Lim