Crie a tabela de tarefas

A tabela tarefas precisa identificar o cadastro associado a cada linha. O campo user_id guarda essa referência e será usado pelas políticas de acesso. O exemplo abaixo cria uma tabela nova no schema public do projeto de estudo.

Execute o schema no SQL Editor

Abra uma consulta nova e execute o trecho uma vez. O código cria a tabela e ativa RLS (Row Level Security) na mesma transação.

1
begin;
2
create table public.tarefas (
3
  id uuid primary key default gen_random_uuid(),
4
  user_id uuid not null references auth.users(id) on delete cascade,
5
  titulo text not null check (char_length(titulo) between 1 and 200),
6
  concluida boolean not null default false,
7
  criada_em timestamptz not null default now()
8
);
9
alter table public.tarefas enable row level security;
10
commit;

A chave primária identifica cada tarefa. A referência a auth.users exige um cadastro existente no Auth. A exclusão desse cadastro remove suas tarefas porque a relação declara on delete cascade. Essa consequência faz parte do exemplo e deve ser revista caso sua aplicação precise preservar registros após excluir um cadastro.

Confira as colunas

No Table Editor, abra tarefas e confira os tipos das colunas. A coluna concluida recebe false quando a inserção não informa outro valor. O limite de tamanho do título fica no próprio banco, então uma chamada direta à API também precisa respeitá-lo.

A aplicação ainda não tem acesso

A tabela foi criada com segurança por linha ativada e ainda não possui as políticas deste exercício. O painel administrativo pode mostrar registros com privilégios diferentes daqueles usados pelo frontend. Por isso, a leitura no painel não comprova que a sessão da aplicação consegue consultar a tabela.

Continue pela etapa de autenticação. Depois dela, você poderá relacionar a identidade da sessão ao campo user_id e conceder somente as ações previstas no exemplo.