ERROR: cannot drop table authors because other objects depend on it (SQLSTATE 2BP01) means a view, a foreign key or another object still refers to the table. The DETAIL line lists every one of them. Drop or change those objects first, or use DROP TABLE ... CASCADE once you know what it will remove.

Read the DETAIL list before reaching for CASCADE: it removes the listed objects without asking again. Running it inside BEGIN lets you read the notice and still roll back.

The error

DROP TABLE authors;
psql:/tmp/q3.sql:7: ERROR:  cannot drop table authors because other objects depend on it
DETAIL:  constraint books_author_id_fkey on table books depends on table authors
view author_names depends on table authors
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

Why it happens

PostgreSQL records dependencies between objects. The foreign key books_author_id_fkey points from books to authors, and the view author_names selects from authors. Dropping the table alone would leave a constraint pointing at nothing and a view reading a table that no longer exists, so a plain DROP TABLE refuses.

This usually shows up when a migration or a reset script drops tables in the wrong order, or when someone created a reporting view on a table that a script then tries to rebuild.

The fix

Drop the dependants yourself, in order. This was run inside a transaction and rolled back:

BEGIN;
BEGIN
DROP VIEW author_names;
DROP VIEW
ALTER TABLE books DROP CONSTRAINT books_author_id_fkey;
ALTER TABLE
DROP TABLE authors;
DROP TABLE
ROLLBACK;
ROLLBACK

Or let CASCADE do it, and read what it says:

BEGIN;
BEGIN
DROP TABLE authors CASCADE;
psql:/tmp/q3.sql:18: NOTICE:  drop cascades to 2 other objects
DETAIL:  drop cascades to constraint books_author_id_fkey on table books
drop cascades to view author_names
DROP TABLE

Note what CASCADE did and did not remove. The view is gone. From books it dropped only the foreign key constraint: the table and its row stayed (SELECT count(*) AS books_left FROM books returned 1 afterwards, and \d books no longer listed a foreign key). So the books now hold author ids that point nowhere. That is usually fine for a reset script and rarely what you want in production. From .NET, Npgsql reports this as a PostgresException with SqlState 2BP01.

How it was reproduced

A postgres:18 container (PostgreSQL 18.4, Debian build 18.4-1.pgdg13+1) on Docker 29.9.2, with authors, books referencing it, a view author_names over authors, and one fictional author and book. DROP TABLE authors failed as shown; both fixes ran inside a transaction, the first rolled back and the CASCADE one committed. A verbose run printed ERROR: 2BP01.

Frequently asked

How do I fix 'cannot drop table because other objects depend on it'?
Read the DETAIL line, which lists the dependent objects, drop or alter them first, then drop the table. Or use DROP TABLE name CASCADE after checking that list.
Does DROP TABLE CASCADE delete the tables that reference it?
No. For a referencing table it drops only the foreign key constraint; the table and its rows stay. The view built on the dropped table here was dropped completely.
How can I see what DROP ... CASCADE will remove before it happens?
Run it inside BEGIN. The NOTICE lists every object it cascades to, and you can ROLLBACK if the list is longer than you expected.

More decoded errors in the Fixes category. For how foreign keys behave when rows, not tables, are deleted, see violates foreign key constraint (23503).