Наверное многие уже знают правильный ответ. В конце концов, указанные команды несложно повторить и увидеть, что единственная команда, которая завершится ошибкой это DELETE:
DELETE FROM t;
ERROR: permission denied for table t
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."t" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x"
Но как удаление только что добавленной строки может завершиться ошибкой? Почему у суперпользователя не хватает прав на таблицу t? И откуда взялась команда SELECT из контекста?
Все дело в ограничении внешнего ключа в таблице t: столбец parent_id ссылается на id этой же таблицы. Для реализации внешних ключей в PostgreSQL используются табличные триггеры. Их называют системными. Это триггеры на языке C, они создаются автоматически, команды psql их не показывают. Но их можно найти в системном каталоге pg_trigger, например в таблице t их сейчас 4. При удалении сработал триггер на DELETE. В триггере проверялось, что на удаляемую строку другие строки не ссылаются.
Так вот оказывается, что системные триггеры выполняются с правами владельца таблицы, а не с правами вызывающего команду DELETE. После выполнения REVOKE, прав на таблицу у app_owner нет. Поэтому любые пользователи будут получать подобные ошибки. Но если права вернуть, то всё заработает:
GRANT ALL ON t TO app_owner;
DELETE FROM t WHERE id = 1;
DELETE 1
Подобное поведение будет неожиданным для пришедших из других СУБД, где забирать у владельцев права на объекты вполне допустимо.
Но неожиданности в реализации системных триггеров на этом не заканчиваются. В недавней статье Broken foreign keys: how can that happen in PostgreSQL? Лауренц Альбе дает хорошее введение в системные триггеры и рассказывает как сломать ограничение внешнего ключа "законными" действиями.
Общий вывод: чтобы не нарушить согласованность данных, нужно учитывать работу системных триггеров. Это особенно важно при разработке собственных табличных триггеров.