Extension to the current "Copy as Markdown" function

[peanutsee]

Currently, the "Copy as Markdown" function in the Schema Visualizer generates a SCHEMA.md file that acts as a fantastic single source of truth for database structure, detailing tables, entity relationships, and data validation rules.

However, two critical components of a PostgreSQL/Supabase architecture are missing from this output: Custom Types/Enums and Row Level Security (RLS) Policies. Because policies dictate how data is accessed and protected, and enums define strict data categories, their absence means the generated Markdown is an incomplete representation of the schema. Developers currently have to manually document these or run separate SQL queries to maintain a true single source of truth.

Describe the solution you'd like
I would love to see the "Copy as Markdown" feature extended to automatically append sections for Enums and Policies associated with the visualized tables.

Ideally, the generated SCHEMA.md would include:

Enums: A list of custom types and their permitted values.

Policies: A breakdown of RLS policies per table, detailing the policy name, command (SELECT, INSERT, etc.), roles, and the USING / WITH CHECK expressions.

[FaustoMendezcom]

The current SCHEMA.md output is great for getting a quick overview of tables and relationships, but as soon as you try to use it as a real single source of truth (handing it to a teammate, feeding it to an LLM, or doing a security review), the missing Enums and RLS policies become a huge blind spot.

In a Supabase/Postgres project, RLS is the schema for all practical purposes — two tables with identical columns can behave completely differently depending on their policies. Leaving them out of the export means the Markdown can actually be misleading, not just incomplete.

A few things that would make this even more useful when implemented:

• Include USING and WITH CHECK expressions verbatim so the doc round-trips back to SQL cleanly
• List which roles each policy applies to (authenticated, anon, service_role, custom)
• For enums, show the underlying type name and the ordered list of values
• Optionally group policies under each table heading rather than in a separate section, so each table reads as a self-contained spec

[ysajang]

I'd like to work on this!

Building on @FaustoMendezcom's suggestions, here's my proposed approach:

1. Enums section

• Query pg_type + pg_enum to get custom enum types and their ordered values
• Append a ## Custom Types / Enums section to the generated markdown

2. RLS Policies section

• Query pg_policies to get policy name, command, roles, USING and WITH CHECK expressions
• Group policies under each table heading (as suggested) so each table reads as a self-contained spec

Output format example:

## Enums

### order_status
`pending` | `processing` | `shipped` | `delivered` | `cancelled`

## Table: orders

### Columns
...

### RLS Policies

| Policy | Command | Roles | USING | WITH CHECK |
|--------|---------|-------|-------|------------|
| users_own_orders | SELECT | authenticated | auth.uid() = user_id | — |

Questions for maintainers:

• Should policies be grouped under each table (self-contained) or in a separate section at the bottom?
• Any preference on including/excluding permissive vs restrictive policy type info?

Happy to submit a draft PR for feedback.

[ysajang]

I've submitted a PR for this: #46189

The implementation adds two new sections to the generated markdown:

• Custom Types / Enums: lists each enum with its ordered values
• RLS Policies: grouped by table with policy name, command, roles, action, USING, and WITH CHECK expressions

Reuses existing useEnumeratedTypesQuery and useDatabasePoliciesQuery hooks. Includes unit tests.

[peanutsee]

I plan to add simple payload mapping to your PR as part of a feature to bring in this discussion. Is that ok with you?