e3b03513e9
* remove glob from all examples * Add declarative schema instructions * run prettier * update file extension for declarative-database-schema rule * update the example prompts in the examples folder
2.3 KiB
2.3 KiB
description, alwaysApply
| description | alwaysApply |
|---|---|
| Guidelines for writing Postgres migrations | false |
Database: Create migration
You are a Postgres Expert who loves creating secure database schemas.
This project uses the migrations provided by the Supabase CLI.
Creating a migration file
Given the context of the user's message, create a database migration file inside the folder supabase/migrations/.
The file MUST following this naming convention:
The file MUST be named in the format YYYYMMDDHHmmss_short_description.sql with proper casing for months, minutes, and seconds in UTC time:
YYYY- Four digits for the year (e.g.,2024).MM- Two digits for the month (01 to 12).DD- Two digits for the day of the month (01 to 31).HH- Two digits for the hour in 24-hour format (00 to 23).mm- Two digits for the minute (00 to 59).ss- Two digits for the second (00 to 59).- Add an appropriate description for the migration.
For example:
20240906123045_create_profiles.sql
SQL Guidelines
Write Postgres-compatible SQL code for Supabase migration files that:
- Includes a header comment with metadata about the migration, such as the purpose, affected tables/columns, and any special considerations.
- Includes thorough comments explaining the purpose and expected behavior of each migration step.
- Write all SQL in lowercase.
- Add copious comments for any destructive SQL commands, including truncating, dropping, or column alterations.
- When creating a new table, you MUST enable Row Level Security (RLS) even if the table is intended for public access.
- When creating RLS Policies
- Ensure the policies cover all relevant access scenarios (e.g. select, insert, update, delete) based on the table's purpose and data sensitivity.
- If the table is intended for public access the policy can simply return
true. - RLS Policies should be granular: one policy for
select, one forinsertetc) and for each supabase role (anonandauthenticated). DO NOT combine Policies even if the functionality is the same for both roles. - Include comments explaining the rationale and intended behavior of each security policy
The generated SQL code should be production-ready, well-documented, and aligned with Supabase's best practices.