Краткий ответ

Права доступа обычно принадлежат конкретному объекту схемы, а не его текстовому имени. После удаления таблицы старый объект исчезает, а новая таблица с тем же именем получает другой идентификатор и не наследует выданные ранее права автоматически.

Исторический контекст

Модель привилегий SQL разделяет имя объекта и сам объект. Это позволяет безопасно переименовывать объекты, различать одноимённые объекты в разных схемах и контролировать доступ к каждому объекту независимо.

Такой подход решает проблему случайного переноса доступа: создание нового объекта с прежним именем не должно неожиданно предоставлять пользователям полномочия, выданные для старого объекта.

Постановка проблемы

Представим, что приложению разрешено читать таблицу, а затем администратор удаляет её и создаёт заново с тем же именем. Если бы права автоматически переносились по имени, приложение могло бы получить доступ к новому объекту без явного решения администратора.

Неверное предположение о сохранении прав приводит к двум типам проблем: приложение внезапно получает ошибки доступа либо, наоборот, новая таблица оказывается доступна не тем пользователям. Особенно опасен второй сценарий при миграциях и автоматическом развёртывании схемы.

Подробное решение

При выполнении DROP TABLE удаляется сам объект таблицы, включая связанные с ним метаданные доступа. Повторное создание таблицы формирует новый объект, даже если совпадают имя, схема и структура столбцов.

CREATE TABLE app.orders (id INTEGER);
GRANT SELECT ON app.orders TO analyst;

DROP TABLE app.orders;
CREATE TABLE app.orders (id INTEGER);

После последнего создания право SELECT, выданное роли analyst для старой таблицы, не следует считать действующим для новой. Доступ может появиться только через явно выданную привилегию, права владельца или настроенные в конкретной СУБД права по умолчанию для новых объектов.

Удаление таблицы может также затронуть зависимые объекты, если используется каскадное удаление. Это не превращает новую таблицу в продолжение старой: зависимости и права нужно рассматривать заново.

Практически безопаснее изменять существующую таблицу через ALTER TABLE, когда требуется сохранить её идентичность и связанные настройки. Если объект действительно нужно пересоздать, миграция должна явно определить владельца, привилегии и зависимости; точный синтаксис и детали наследования прав зависят от СУБД.

Ситуация из практики

В релизе требовалось изменить структуру таблицы, доступную аналитической роли. Команда выбрала между удалением с последующим созданием и изменением существующего объекта.

Удаление и создание проще концептуально, но требует повторного назначения прав, восстановления зависимых представлений и проверки владельца. Кроме того, окно между операциями может привести к отсутствию объекта или к ошибкам параллельных запросов.

Изменение через ALTER TABLE сохраняет идентичность таблицы и обычно сохраняет её права и зависимости, хотя отдельные изменения могут блокироваться, переписывать данные или требовать длительной блокировки. Поэтому было выбрано поэтапное ALTER TABLE с отдельной проверкой блокировок и прав.

После миграции приложение продолжило работать с прежними полномочиями, а новые права не появились неявно. Для операции пересоздания потребовался бы явный этап восстановления доступа.

Что кандидаты часто упускают

Сохраняются ли права при переименовании таблицы?

Обычно да: переименование изменяет имя существующего объекта, но не создаёт новый объект. Поэтому выданные ему привилегии остаются связанными с тем же объектом. Однако ссылки приложений и неквалифицированные имена всё равно нужно проверить.

Достаточно ли совпадения имени и структуры, чтобы объект считался прежним?

Нет. Имя и структура — свойства объекта, но не его идентичность. Система различает объекты внутренними идентификаторами или аналогичными метаданными, поэтому две последовательно созданные таблицы с одинаковым именем и столбцами являются разными объектами.

Могут ли права появиться у новой таблицы без явного GRANT?

Да, если СУБД поддерживает и настроила права по умолчанию, если роль является владельцем новой таблицы или доступ предоставляется через более общий механизм, например членство в роли. Но это не означает переноса прав от удалённой таблицы: источник доступа нужно определить отдельно.