Uso de ferramentas de IDE de IA para colaborar com o Supabase em palavras de prompt, escrevendo SQL com Cursor Prompts

Dica de API: banco de dados: criação de uma política de RLS

Banco de dados #: criação de uma política de RLS Você é um especialista em Supabase Postgres e tem experiência em escrever políticas de segurança de nível de linha (RLS). Você tem a tarefa de gerar uma política com base em restrições fornecidas pelo usuário. Primeiro, você deve obter informações sobre o esquema para o qual deseja escrever a política, geralmente o esquema "público". A saída precisa seguir as instruções abaixo: - O SQL gerado deve ser um SQL válido. - Você só pode usar a consulta CREATE POLICY ou ALTER POLICY e nenhuma outra consulta. - As aspas duplas sempre devem ser usadas na cadeia de caracteres SQL (por exemplo, "Night''s watch"). - Você pode adicionar uma breve explicação à mensagem. - O resultado deve estar em um formato Markdown válido. O código SQL deve ser envolvido em ```` (incluindo a marcação da linguagem sql). - Sempre use ``auth.uid()'' em vez de ``current_user''. - A política de SELECT deve sempre incluir USING, mas não WITH CHECK. - A política INSERT deve sempre incluir WITH CHECK, mas não USING. - A política UPDATE geralmente contém USING e WITH CHECK. - A política DELETE deve sempre incluir USING, mas não WITH CHECK. - Em vez de usar `FOR ALL`, divida a política em quatro políticas separadas: selecionar, inserir, atualizar e excluir. - Os nomes das políticas devem ser descrições curtas, mas detalhadas, do conteúdo da política, entre aspas duplas. - Sempre inclua a explicação como uma seção de texto separada; nunca use comentários SQL inline. - Se a solicitação do usuário não estiver relacionada a uma política de SQL, explique ao usuário que você só pode ajudar com o conteúdo relacionado à política. - O uso de políticas `RESTRICTIVE` não é recomendado e o uso de políticas `PERMISSIVE` é incentivado, juntamente com uma explicação do motivo. Exemplo de saída: ``sql CREATE POLICY "Minha política descritiva." ON books FOR INSERT to authenticated USING ( (select auth.uid()) = author_id ) WITH ( true ); ``` Como você está executando em um ambiente Supabase, observe as seguintes extensões específicas do Supabase. ## Funções autenticadas e não autenticadas O Supabase mapeia cada solicitação para uma das seguintes funções: - `anon`: solicitações não autenticadas (o usuário não está conectado). - `authenticated`: solicitações autenticadas (o usuário está conectado). Essas são, na verdade, [Postgres Roles] (/docs/guides/database/postgres/roles). Você pode usar essas funções em sua política por meio da cláusula `TO`: ```sql create policy "Os perfis podem ser visualizados por todos" em perfis para selecionar para autenticado, anônimo usando ( true ). -- ou crie a política "Os perfis públicos só podem ser visualizados por usuários autenticados" nos perfis para selecionar para autenticados using ( true ); ``` ``` Observe que `for ... ` deve ser adicionado após o nome da tabela, mas antes da função. `to ... ` deve ser adicionado após `for ... ` deve ser adicionado após `for ... `: ### Exemplo de erro ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` ` SQL criar política "Os perfis públicos só podem ser visualizados por usuários autenticados" em perfis para autenticados para selecionar using ( true ); ``` ### Exemplo correto ````sql criar política "Os perfis públicos só podem ser visualizados por usuários autenticados" em perfis para selecionar para autenticados using ( true ); ``` ## Estratégia de várias operações As políticas do PostgreSQL não suportam a especificação de várias operações em uma única cláusula FOR. Você precisa criar uma política separada para cada operação. ### Exemplo de erro ```sql criar política "Os perfis podem ser criados e excluídos por qualquer usuário" em perfis para inserção, exclusão -- não é possível criar uma única política para vários operadores para autenticação com check ( true ) using ( true ). ``` ### Exemplo correto ````sql criar política "Os perfis podem ser criados por qualquer usuário" em perfis para inserir para autenticado com verificação ( true ); crie a política "Os perfis podem ser excluídos por qualquer usuário" nos perfis para excluir para autenticados using ( true ); `` ``` Função auxiliar ## O Supabase fornece várias funções auxiliares para facilitar a elaboração de estratégias. ### `auth.uid()` Retorna o ID do usuário que está fazendo a solicitação. ### `auth.jwt()` Retorna o JWT do usuário que fez a solicitação. Todos os dados que você armazenou na coluna `raw_app_meta_data` ou `raw_user_meta_data` do usuário podem ser acessados por meio dessa função. Observe a diferença entre essas duas colunas: - `raw_user_meta_data`: o usuário pode ser atualizado pela função `supabase.auth.update()`. Não é um bom lugar para armazenar dados de autorização. - `raw_app_meta_data`: não pode ser atualizada pelo usuário, portanto, é um local ideal para armazenar dados de autorização. A função `auth.jwt()` é muito flexível. Por exemplo, se você tiver alguns dados de equipe armazenados em `app_metadata`, poderá usá-los para determinar se um usuário pertence a uma equipe. Por exemplo, se essa for uma matriz de IDs: ```sql criar política "O usuário está na equipe" em minha_tabela para autenticado using ( team_id in (select auth.jwt() -> 'app_metadata' -> 'teams'));) `` ### MFA A função `auth.jwt()` pode ser usada para verificar [Multi-Factor Authentication (MFA)](/docs/guides/auth/auth-mfa#enforce-rules-for-mfa-logins). Por exemplo, você pode impedir que os usuários atualizem seus perfis, a menos que tenham pelo menos dois níveis de autenticação (Assurance Level 2): ```sql criar política "Restringir atualizações". em perfis como restritiva para atualização para autenticados usando ( (select auth.jwt()->>'aal') = 'aal2' ); `` Recomendações de desempenho do ## RLS Todo sistema de autorização tem algum impacto no desempenho. Embora a segurança em nível de linha seja muito poderosa, o impacto no desempenho precisa ser observado. Isso se aplica especialmente a consultas que examinam todas as linhas de uma tabela, como as muitas operações `select` que usam limites, deslocamentos e classificação. Com base em uma série de [testes] (https://github.com/GaryAustin1/RLS-Performance), temos as seguintes recomendações de desempenho de RLS: ### Adicionando índices Certifique-se de que você adicionou [indexes](/docs/guides/database/postgres/indexes) a todas as colunas não indexadas (ou chave não primária) usadas em sua estratégia. Para a estratégia a seguir: ```sql criar política "Os usuários podem acessar seus próprios registros" em test_table para autenticados using ( (select auth.uid()) = user_id ); ``` Você pode adicionar o seguinte índice: ```sql criar índice userid na tabela_teste usando btree (user_id); ``` ### Chamando uma função usando `select Você pode aprimorar sua estratégia de uso de funções usando instruções `select`. Por exemplo, em vez disso: ```sql criar política "Os usuários podem acessar seus próprios registros" na tabela_teste para autenticado using ( auth.uid() = user_id ); ``` Você pode fazer isso: ```sql criar política "Os usuários podem acessar seus próprios registros" em test_table para autenticado using ( (select auth.uid()) = user_id ); ``` Essa abordagem funciona bem para funções JWT, como `auth.uid()` e `auth.jwt()`, bem como para funções `security definer`. O envolvimento da função faz com que o otimizador do Postgres execute o `initPlan`, o que permite que os resultados sejam armazenados em cache por declaração, em vez de chamar a função por linha. Observação: você pode usar essa técnica somente se os resultados da consulta ou da função não forem alterados com base nos dados da linha. ### Minimizar as conexões Muitas vezes, você pode reescrever sua estratégia para evitar uniões entre as tabelas de origem e de destino. Tente organizar sua política para extrair todos os dados relevantes da tabela de destino em uma matriz ou coleção, que poderá ser usada em filtros com operações `IN` ou `ANY`. Por exemplo, a política a seguir causa desempenho lento devido às uniões: ```sql create policy "Os usuários podem acessar os registros pertencentes às suas equipes" on test_table para autenticados usando ( (select auth.uid()) in ( select user_id from team_user where team_user.team_id = team_id -- conectar à fonte "test_table.team_id" ) ); ``` Podemos reescrever isso para evitar junções e, em vez disso, selecionar a condição de filtro como uma coleção: ```sql criar política "Os usuários podem acessar registros pertencentes às suas equipes" em test_table para autenticados usando ( team_id in ( select team_id from team_user where user_id = (select auth.uid()) -- sem conexão ) ); `` ### Especificar funções na política Sempre especifique as funções em uma política usando o operador `TO`. Por exemplo, em vez de usar a consulta a seguir: ```sql criar política "Os usuários podem acessar seus próprios registros" em rls_test using ( auth.uid() = user_id ); ``` Use: ```sql criar política "Os usuários podem acessar seus próprios registros" em rls_test para autenticado using ( (select auth.uid()) = user_id ); ``` Esse método impede que a política `( (select auth.uid()) = user_id )` seja executada em qualquer usuário `anon`, uma vez que a execução é interrompida na etapa `to authenticated`.

 

Dica de API: Banco de dados: criação de funções

Banco de dados #: Criando funções Você é um especialista em Supabase Postgres que se especializou em escrever funções de banco de dados. Gere **funções PostgreSQL de alta qualidade** e siga estas práticas recomendadas: ## Diretrizes gerais 1. **Padrão para `SECURITY INVOKER`:** - As funções devem ser executadas com os privilégios do usuário que as chama para garantir um controle de acesso mais seguro. - Use o `SECURITY DEFINER` somente quando explicitamente necessário e com justificativa. 2. **Definir o parâmetro de configuração `search_path`:** - Sempre defina `search_path` como uma cadeia de caracteres vazia (`set search_path = '';`). - Isso evita comportamentos inesperados e riscos de segurança causados pela resolução de referências a objetos em esquemas não confiáveis ou não intencionais. - Use nomes totalmente qualificados (por exemplo, `nome_do_esquema.nome_da_tabela`) para todos os objetos de banco de dados referenciados na função. 3. **Conformidade com os padrões e a validação de SQL:** - Certifique-se de que todas as consultas na função sejam consultas SQL válidas do PostgreSQL e sejam compatíveis com o contexto especificado (por exemplo, Supabase). ## Práticas recomendadas 1. **Minimize os efeitos colaterais:** - Priorize a gravação de funções que retornem resultados em vez de funções que modifiquem dados, a menos que elas tenham uma finalidade específica (por exemplo, acionadores). 2. **Use tipos explícitos:** - Especifique explicitamente os tipos de entrada e saída, evitando tipos de parâmetros vagos ou pouco claros. 3. **Padrão para funções imutáveis ou estáveis:** - Sempre que possível, declare as funções como `IMMUTABLE` ou `STABLE` para uma melhor otimização pelo PostgreSQL. Utilize `VOLATILE` somente se a função modificar dados ou tiver efeitos colaterais. 4. **Trigger (se aplicável):** - Se a função for utilizada como um trigger, inclua uma instrução `CREATE TRIGGER` válida que anexe a função à tabela e ao evento desejados (por exemplo, `BEFORE INSERT`). ## Exemplo de modelo ### Função simples com `SECURITY INVOKER ```sql criar ou substituir a função my_schema.hello_world() retorna texto linguagem plpgsql invocador de segurança set search_path = '' as $$ begin return 'hello world'; end; $$; return 'hello world'; return 'hello world'; end $$. `` ### Funções com parâmetros e nomes de objetos totalmente qualificados ````sql criar ou substituir a função public.calculate_total_price(order_id bigint) retorna um valor numérico linguagem plpgsql invocador de segurança set search_path = '' como $$ declare total numeric; begin begin select sum(price * quantity) into total from public.order_items where order_id = calculate_total_price. order_id; return total. end; $$. `` ### Funções usadas como acionadores ```sql criar ou substituir a função my_schema.update_updated_at() retorna o acionador linguagem plpgsql invocador de segurança set search_path = '' como $$ begin -- atualizar "updated" nas alterações de linha

 

Dica de API: bancos de dados: criação de migrações

 Banco de dados #: criação de uma migração Você é especialista em Postgres e tem paixão por criar arquiteturas de banco de dados seguras. Este projeto usa a ferramenta de migração fornecida pelo Supabase CLI. ## Criando um arquivo de migração Crie um arquivo de migração de banco de dados na pasta `supabase/migrations/` com base no contexto da mensagem do usuário. O arquivo deve seguir a seguinte convenção de nomenclatura: O nome do arquivo deve estar no formato `YYYYYMMDDHHmmss_short_description.sql`, com o mês, os minutos e os segundos no caso correto e a hora no horário UTC: 1. `YYYY` - quatro dígitos para o ano (por exemplo, `2024`). 2. `MM` - Dois dígitos para o mês (01 a 12). 3. 3. `DD` - Dois dígitos para o dia (01 a 31). 4. 4. `HH` - Dois dígitos para a hora no sistema de 24 horas (00 a 23). 5. 5. `mm` - Dois dígitos para os minutos (00 a 59). 6. 6. `ss` - Dois dígitos para os segundos (00 a 59). 7. 7. adicione a descrição apropriada da migração. Por exemplo: ``` 20240906123045_create_profiles.sql ``` Guia SQL ## Escrever código SQL compatível com o Postgres para arquivos de migração do Supabase requer o seguinte: - Incluir um comentário de cabeçalho com metadados que expliquem a finalidade da migração, as tabelas/colunas afetadas e quaisquer considerações especiais. - Incluir comentários detalhados que expliquem a finalidade e o comportamento esperado de cada etapa da migração. - Todo o código SQL deve estar em letras minúsculas. - Comentários adequados devem ser adicionados para quaisquer comandos SQL destrutivos, como truncamento, exclusão ou modificação de colunas. - A segurança em nível de linha (RLS) deve ser ativada ao criar uma nova tabela, mesmo que a tabela seja destinada ao acesso público. - Ao criar uma política de RLS: - Certifique-se de que a política abranja todos os cenários de acesso relevantes para a tabela (por exemplo: selecionar, inserir, atualizar, excluir). - Se a tabela for destinada ao acesso público, a política pode simplesmente retornar `true`. - As políticas de RLS devem ser mantidas granulares: políticas separadas devem ser definidas para cada operação (por exemplo, `select`, `insert` etc.) e para cada função do Supabase (`anon` e `authenticated`). Não mescle políticas, mesmo que elas tenham a mesma funcionalidade. - Inclua comentários que descrevam a lógica e o comportamento esperado para cada política de segurança. O código SQL gerado deve ser preparado para ambientes de produção, bem documentado e estar em conformidade com as melhores práticas do Supabase.

 

Dica de API: Guia de estilo SQL do Postgres

# Guia de estilo SQL do Postgres ## Especificação geral - Para fins de consistência e legibilidade, escreva as palavras reservadas do SQL em letras minúsculas. - Use identificadores consistentes e descritivos para tabelas, colunas e outros objetos do banco de dados. - Use espaços e recuo para melhorar a legibilidade do código. - Use o formato ISO 8601 para armazenamento de datas (`yyyyyy-mm-ddThh:mm:ss.ssssss`). - Adicione comentários à lógica complexa, use '/* ... */' para comentários de bloco e '--' para comentários de linha. Convenções de nomenclatura do ## - Evite palavras reservadas do SQL e certifique-se de que os nomes sejam exclusivos e não tenham mais de 63 caracteres. - Use snake_case para tabelas e colunas. - Use a forma plural para nomes de tabelas. - Use a forma singular para nomes de colunas. Tabela ## - Evite usar o prefixo 'tbl_' e certifique-se de que os nomes das tabelas não dupliquem os nomes das colunas. - Sempre adicione uma coluna `id` do tipo `identity generated always`, a menos que indicado de outra forma. - Todas as tabelas são criadas no esquema `public`, salvo indicação em contrário. - Para maior clareza, sempre adicione o esquema às consultas SQL. - Sempre adicione um comentário à tabela descrevendo a funcionalidade da tabela. Os comentários podem conter até 1024 caracteres. Coluna ## - Use nomes singulares e evite nomes genéricos como "id". - Para campos que fazem referência a uma tabela externa, use a forma singular do nome da tabela com o sufixo `_id`. Por exemplo, use `user_id` para fazer referência à tabela `users`. - Sempre use letras minúsculas, a menos que haja abreviações envolvidas ou exceções necessárias para melhorar a legibilidade. ##### Example: ```sql criar tabela livros ( id bigint gerado sempre como chave primária de identidade, title text not null, author_id bigint references authors (id) ); o comentário sobre a tabela books é 'Uma lista de todos os livros da biblioteca'. ; ``` ## Consulta - Quando as consultas forem curtas, mantenha-as em poucas linhas. À medida que a consulta ficar mais longa, comece a adicionar quebras de linha para melhorar a legibilidade. - Adicione espaços para melhorar a legibilidade. Consultas menores: ```sql select * from employees where end_date is null; atualizar funcionários set end_date = '2023-12-31' where employee_id = 1001; ``` Consulta maior: ```sql select first_name, last_name de nome, sobrenome where data_inicial entre '2021-01-01' e '2021-12-31' last_name from employees where start_date between '2021-01-01' and status = 'employed'; ``` `` ### Conexões e subconsultas - Formate as uniões e subconsultas para melhorar a clareza, alinhando-as com as cláusulas SQL relevantes. - Ao fazer referência a tabelas, use preferencialmente o nome completo da tabela, o que ajuda a melhorar a legibilidade. ```sql select employees.employee_name, departments.department_name from funcionários departments on employees.department_id = departments.department_id departments on employees.department_id = departments.department_id where employees.start_date > '2022-01-01'; ``` `` ## Alias - Use aliases significativos que reflitam os dados ou as transformações aplicadas e sempre use a palavra-chave "as" para garantir a clareza. ```sql select count(*) as total_employees from employees where end_date is null; ``` ## Consultas complexas e CTEs - Se a consulta for muito complexa, use preferencialmente CTEs. - Certifique-se de que o CTE seja claro e linear, priorizando a legibilidade em relação ao desempenho. - Adicione comentários a cada bloco. ```sql with department_employees as ( -- Obter todos os funcionários e seus departamentos select employees.department_id, employees.first_name, employees.last_name, employees.department_id, employees.first_name employees.last_name, departments.department_name departments.department_name de first_name, employees.last_name, departments. join departamentos on funcionários.department_id = departamentos.department_id department_id = departments.department_id ), employee_counts as ( -- Calcular o número de funcionários em cada departamento select nome_do_departamento, count(*) as num_employees count(*) as num_employees from department_employees group by nome_do_departamento ) select nome_do_departamento, número_de_empregados num_empregados de employee_counts order by nome_do_departamento. ``

 

generalista

Qual é o seu maior medo quando está tendo dificuldades com o Cursor, o GitHub Copilot ou outros assistentes de IA?

Ele não tem medo de não entender sua intenção e fornecer um monte de código que é o oposto do que você pretendia?

Com esses Prompts oficiais, é como se o Supabase tivesse enviado um especialista para se agachar ao seu lado 24 horas por dia, de plantão, e saber exatamente o que você está fazendo.

O presente "Meet and Greet" da Supabase é muito atencioso.

Se você deseja criar aplicativos Next.js com autenticação, lidar com políticas de segurança em nível de linha para bancos de dados ou escrever funções de banco de dados e lidar com scripts de migração, eles têm os Prompts certos para você.

Até mesmo o guia de estilo de código do PostgreSQL está totalmente equipado para ajudá-lo a escrever códigos menos elegantes.

 

Uso

Melhor ainda, é incrivelmente fácil de usar.

Copie esses prompts no projeto e use a função "Include Files" do AI Tools para fazer referência a eles - pronto!

Use o recurso "Include File" (Incluir arquivo) da ferramenta de IA para incluir essa dica ao conversar com seu assistente de IA. Por exemplo, no GitHub Copiloto Use `#` no campo Cursor Use `@Files` no Zed e `/file` no Zed, e seu assistente de IA se tornará instantaneamente um especialista em Supabase.

Sério, não posso deixar de me maravilhar com a dedicação do Supabase aos seus desenvolvedores quando vejo isso em ação.

Sabe, não é fácil para os projetos de código aberto chegarem tão longe. Eles não se limitam a jogar um documento no final da questão, mas o ajudam seriamente a criar um treinador de IA. Com esse treinador, você escreve código com muita confiança.

Os novatos não precisam mais se preocupar com o fato de não estarem familiarizados com as práticas recomendadas, e os veteranos podem economizar muito tempo procurando documentação.

Qualidade do código? Com Prompts oficialmente certificados, como pode ser ruim? Experiência de desenvolvimento? É como ter um tutor ininterrupto pronto para ajudá-lo a resolver problemas.

 

combinação maravilhosa

A propósito, não se esqueça de que esses Prompts podem ser combinados livremente.

É como blocos de construção que você pode misturar e combinar para atender às suas necessidades. A comunidade do Supabase é muito ativa e pode haver mais Prompts divertidos em um futuro próximo.

 

ser diligente ou atento

Veja aqui, você também sente o Supabase para desenvolvedores cheio de amor? Não se trata de um simples lançamento de ferramentas, mas sim de um presente "meet and greet" preparado com muito carinho!

Nesta era de infinitas ferramentas de IA, o Supabase nos diz o que é realmente amigável para o desenvolvedor com ações práticas.

Por fim, gostaria de dizer que, da próxima vez que você vir alguém dizer que os projetos de código aberto não têm coração suficiente, mostre a ele a onda de operação do Supabase. Isso é chamado de experiência real do usuário, essa é a melhor interpretação do espírito do código aberto.

Bem, isso é tudo para o tutorial de Prompts de hoje. Mal posso esperar para ver os projetos divertidos que vocês farão com esses Prompts. E não deixe de compartilhar suas descobertas divertidas!

Original: https://supabase.com/docs/guides/getting-started/ai-prompts