Observe a transação SQL a seguir.No PostgreSQL, após a execução da transação SQL, o(s) registro(s) da tabela Parte é(são):
A(1, 'Mariana Souza')
B(2, 'Joca Silva')
C(3, 'Luiz Almeira')
D(1, 'Mariana Souza')(2, 'Joca Silva')
E(2, 'Joca Silva')(3, 'Luiz Almeira')
Revelar gabarito e comentário▾
GabaritoA — (1, 'Mariana Souza')
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Transações SQL no PostgreSQL: o efeito do ROLLBACK e do SAVEPOINT
Gabarito: letra A. Após a execução da transação, a tabela Parte contém apenas o registro (1, 'Mariana Souza'). Isso ocorre porque o comando ROLLBACK TO SAVEPOINT desfaz as operações realizadas após o ponto de salvamento, mas preserva as operações anteriores a ele — e o COMMIT final confirma apenas o que foi preservado. A questão testa exatamente o comportamento do SAVEPOINT no PostgreSQL, que permite desfazer parte de uma transação sem abortá-la por completo.
O SAVEPOINT é um mecanismo de controle transacional que cria um ponto de restauração dentro de uma transação. Ele é útil quando se deseja desfazer apenas parte do trabalho realizado, sem precisar abortar a transação inteira. O comando ROLLBACK TO SAVEPOINT retorna o estado da transação ao ponto marcado, descartando todas as operações executadas após a criação do savepoint. Diferentemente do ROLLBACK completo, que encerra a transação, o ROLLBACK TO SAVEPOINT mantém a transação ativa, permitindo que novas operações sejam executadas e que a transação seja eventualmente confirmada com COMMIT.
Para entender o que acontece na questão, é preciso acompanhar a sequência de comandos. A transação começa com BEGIN, que inicia uma nova transação. Em seguida, um INSERT adiciona o registro (1, 'Mariana Souza') à tabela Parte. Depois, um SAVEPOINT é criado, marcando o estado atual da transação. A partir daí, um novo INSERT adiciona (2, 'Joca Silva'), e outro INSERT adiciona (3, 'Luiz Almeira'). Quando o comando ROLLBACK TO SAVEPOINT é executado, todas as operações realizadas após a criação do savepoint — ou seja, os dois últimos INSERTs — são desfeitas. O registro (1, 'Mariana Souza'), inserido antes do savepoint, permanece. Por fim, o COMMIT confirma a transação, tornando permanente apenas o registro que sobreviveu ao rollback parcial.
A pegadinha da questão está em confundir o ROLLBACK TO SAVEPOINT com o ROLLBACK completo. Enquanto o ROLLBACK desfaz toda a transação e a encerra, o ROLLBACK TO SAVEPOINT desfaz apenas as operações posteriores ao ponto de salvamento, mantendo a transação ativa. Outra confusão comum é achar que o SAVEPOINT funciona como um COMMIT intermediário, o que não é verdade: o savepoint não confirma nada, apenas marca um ponto de restauração. O COMMIT final é o único responsável por tornar as alterações permanentes.
Guarde a distinção entre os comandos de controle transacional: COMMIT confirma tudo, ROLLBACK desfaz tudo, SAVEPOINT marca um ponto intermediário e ROLLBACK TO SAVEPOINT desfaz apenas o que veio depois do ponto marcado. É exatamente essa hierarquia que separa a alternativa correta das demais.
1BEGIN
2INSERT (1, Mariana)
3SAVEPOINT
4INSERT (2, Joca)
5INSERT (3, Luiz)
6ROLLBACK TO SAVEPOINT
7COMMIT
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa A apresenta apenas o registro (1, 'Mariana Souza'). Isso está correto porque o ROLLBACK TO SAVEPOINT desfez os INSERTs dos registros (2, 'Joca Silva') e (3, 'Luiz Almeira'), que foram executados após a criação do savepoint. O registro (1, 'Mariana Souza'), inserido antes do savepoint, foi preservado e confirmado pelo COMMIT final.
Alternativa B — ❌ Incorreta
A alternativa B apresenta apenas o registro (2, 'Joca Silva'). Esse registro foi inserido após a criação do savepoint e, portanto, foi desfeito pelo ROLLBACK TO SAVEPOINT. A alternativa ignora o efeito do rollback parcial, que remove exatamente as operações posteriores ao ponto de salvamento.
Alternativa C — ❌ Incorreta
A alternativa C apresenta apenas o registro (3, 'Luiz Almeira'). Assim como o registro (2, 'Joca Silva'), o registro (3, 'Luiz Almeira') foi inserido após o savepoint e foi desfeito pelo ROLLBACK TO SAVEPOINT. A alternativa confunde o efeito do rollback parcial com o de um COMMIT que confirmaria todos os inserts.
Alternativa D — ❌ Incorreta
A alternativa D apresenta os registros (1, 'Mariana Souza') e (2, 'Joca Silva'). O erro está em incluir o registro (2, 'Joca Silva'), que foi desfeito pelo ROLLBACK TO SAVEPOINT. A alternativa parece considerar que o rollback parcial desfaz apenas o último INSERT, mas na verdade desfaz todas as operações posteriores ao savepoint, incluindo ambos os inserts.
Alternativa E — ❌ Incorreta
A alternativa E apresenta os registros (2, 'Joca Silva') e (3, 'Luiz Almeira'). Ambos os registros foram inseridos após o savepoint e foram desfeitos pelo ROLLBACK TO SAVEPOINT. A alternativa ignora completamente o efeito do rollback parcial, tratando-o como se não tivesse ocorrido.
A regra de ouro para questões de transação com savepoint é identificar o que foi feito antes e depois do ponto de salvamento: tudo que veio antes sobrevive, tudo que veio depois é desfeito. O COMMIT final apenas confirma o que restou.
No PostgreSQL, após a execução da transação SQL, o(s) registro(s) da tabela Parte é(são):