Questão de Banco de Dados — PostgreSQL — VUNESP 2025

DROP DATABASE no PostgreSQL: quem pode e quando

Gabarito: letra C. No PostgreSQL, o comando DROP DATABASE pode ser executado pelo proprietário do banco de dados, desde que ele não esteja conectado a esse banco no momento da execução — é exatamente o que a alternativa C afirma. As demais alternativas erram ao sugerir reversibilidade, permissão irrestrita, limitação por número de tabelas ou necessidade de autorização do superusuário.

O DROP DATABASE é um comando da DDL (Data Definition Language), responsável por destruir definitivamente uma base de dados, removendo seus arquivos físicos e todo o seu conteúdo. Diferentemente do DELETE ou TRUNCATE, que atuam sobre os dados de uma tabela, o DROP DATABASE elimina a própria estrutura do banco. No PostgreSQL, esse comando é irreversível: não há como desfazer a operação com ROLLBACK, pois a destruição é imediata e definitiva.

A regra de permissão é clara: apenas o proprietário do banco (ou o superusuário) pode executar o DROP DATABASE. Além disso, o PostgreSQL exige que nenhuma sessão esteja conectada ao banco que se deseja eliminar — incluindo a própria sessão que emite o comando. Isso significa que o usuário deve estar conectado a outro banco (como postgres) para poder destruir o banco alvo. Essa restrição existe para evitar conflitos e garantir a integridade do sistema.

Na prática, o fluxo seria: conectar-se ao banco postgres (ou outro), executar DROP DATABASE nome_do_banco; e aguardar a exclusão. Se houver conexões ativas no banco alvo, o comando falhará com um erro. Essa é uma proteção importante que a banca explora nas alternativas.

A pegadinha central desta questão está na combinação de dois requisitos: ser o proprietário e não estar conectado ao banco. O candidato que conhece apenas a regra do proprietário pode marcar a alternativa C sem perceber que ela também exige a desconexão — mas é justamente essa exigência que a torna correta e elimina as demais.

Alternativa A — ❌ Incorreta

Afirma que é possível reverter a destruição de uma base de dados, retornando ao estado anterior. Isso é falso: o DROP DATABASE é irreversível no PostgreSQL. Diferentemente de outros comandos DDL que podem ser executados dentro de uma transação e desfeitos com ROLLBACK, o DROP DATABASE não pode ser revertido. Uma vez executado, o banco e todos os seus dados são perdidos permanentemente. A única forma de "recuperar" seria por meio de um backup prévio, mas isso não é uma reversão do comando em si.

Alternativa B — ❌ Incorreta

Afirma que qualquer usuário pode executar o comando. Isso é incorreto: apenas o proprietário do banco ou o superusuário têm permissão para executar DROP DATABASE. Um usuário comum, sem esses privilégios, receberá um erro de permissão negada. A alternativa confunde a permissão restrita com uma permissão irrestrita, o que é uma pegadinha clássica.

Alternativa C — ✅ Correta ⟵ GABARITO

Afirma que o comando pode ser executado pelo proprietário do banco, desde que ele não esteja conectado a esse banco. Isso está correto e reflete exatamente a regra do PostgreSQL. O proprietário tem o privilégio de destruir o banco, mas o sistema exige que não haja conexões ativas no banco alvo — incluindo a própria conexão do proprietário. Portanto, o proprietário deve estar conectado a outro banco (como postgres) para executar o DROP DATABASE.

Alternativa D — ❌ Incorreta

Afirma que o comando não pode ser executado se o banco contiver mais de 100 tabelas. Isso é absurdo: não existe nenhuma limitação desse tipo no PostgreSQL. O DROP DATABASE pode ser executado independentemente do número de tabelas, índices, visões ou qualquer outro objeto contido no banco. A alternativa inventa um limite numérico que não existe na documentação do SGBD.

Alternativa E — ❌ Incorreta

Afirma que o proprietário deve solicitar autorização do superusuário para executar o comando. Isso é falso: o proprietário já possui a permissão necessária para destruir seu próprio banco, sem precisar de autorização adicional. O superusuário tem privilégios amplos, mas o proprietário não depende dele para executar DROP DATABASE no banco que lhe pertence. A alternativa confunde a hierarquia de privilégios, sugerindo uma dependência que não existe.

Gabarito: letra C