Как удалить схему в postgresql

DROP SCHEMA — удалить схему

Синтаксис

DROP SCHEMA [ IF EXISTS ] имя [, . ] [ CASCADE | RESTRICT ]

Описание

DROP SCHEMA удаляет схемы из базы данных.

Схему может удалить только её владелец или суперпользователь. Заметьте, что владелец может удалить схему (вместе со всеми содержащимися в ней объектами), даже если он не владеет некоторыми объектами в своей схеме.

Параметры

Не считать ошибкой, если схема не существует. В этом случае будет выдано замечание. имя

Имя схемы. CASCADE

Автоматически удалять объекты (таблицы, функции и т. п.), содержащиеся в схеме. RESTRICT

Отказать в удалении схемы, если она содержит какие-либо объекты. Это поведение по умолчанию.

Примеры

Удаление схемы mystuff из базы данных вместе со всем, что в ней содержится:

DROP SCHEMA mystuff CASCADE;

Совместимость

Команда DROP SCHEMA полностью соответствует стандарту SQL, но возможность удалять в одной команде несколько схем и указание IF EXISTS являются расширениями Postgres Pro .

См. также

Пред.	Наверх	След.
DROP RULE	Начало	DROP SEQUENCE

PostgreSQL — Schemas

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

База данных содержит одну или несколько именованных схем , которые, в свою очередь, содержат таблицы. Схемы также содержат другие типы именованных объектов, включая типы данных, функции и операторы. Одно и то же имя объекта может использоваться в разных схемах без конфликтов; например, оба schema1 и myschema могут содержать таблицы с именами mytable . В отличие от баз данных, схемы не разделены жестко: пользователь может получить доступ к объектам в любой из схем в базе данных, к которой он подключен, если у него есть соответствующие привилегии.

Есть несколько причин, по которым можно использовать схемы:

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

Схемы аналогичны каталогам на уровне операционной системы, за исключением того, что схемы не могут быть вложенными.

Создание схемы

Чтобы создать схему, используйте команду CREATE SCHEMA . Дайте схеме имя по вашему выбору. Например:

CREATE SCHEMA myschema;

Чтобы создать или получить доступ к объектам в схеме, напишите полное имя , состоящее из имени схемы и имени таблицы, разделенных точкой:

schema.table

Это работает везде, где ожидается имя таблицы, включая команды изменения таблицы и команды доступа к данным, обсуждаемые в следующих главах. (Для краткости мы будем говорить только о таблицах, но те же идеи применимы и к другим видам именованных объектов, таким как типы и функции.)

На самом деле, даже более общий синтаксис:

database.schema.table

тоже можно использовать, но в настоящее время это только для формального соответствия стандарту SQL. Если вы пишете имя базы данных, оно должно совпадать с именем базы данных, к которой вы подключены.

Итак, чтобы создать таблицу в новой схеме, используйте:

CREATE TABLE myschema.mytable ( . );

Чтобы удалить схему, если она пуста (все объекты в ней удалены), используйте:

DROP SCHEMA myschema;

Чтобы удалить схему, включающую все содержащиеся объекты, используйте:

DROP SCHEMA myschema CASCADE;

Часто вам потребуется создать схему, принадлежащую кому-то другому (поскольку это один из способов ограничить действия ваших пользователей четко определенными пространствами имен). Синтаксис для этого:

CREATE SCHEMA schema_name AUTHORIZATION user_name;

Вы даже можете опустить имя схемы, и в этом случае имя схемы будет таким же, как имя пользователя.

Имена схем, начинающиеся с pg_ , зарезервированы для системных целей и не могут создаваться пользователями.

Публичная схема

В предыдущих разделах мы создавали таблицы без указания имен схем. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему с именем « public » . Каждая новая база данных содержит такую схему. Таким образом, следующие условия эквивалентны:

CREATE TABLE products ( . );

CREATE TABLE public.products ( . );

Путь поиска схемы

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

Возможность создавать объекты с одинаковыми именами в разных схемах усложняет написание запроса, который каждый раз ссылается на одни и те же объекты. Это также открывает для пользователей возможность изменить поведение запросов других пользователей, злонамеренно или случайно. Из-за преобладания неполных имен в запросах и их использования во внутренних компонентах PostgreSQL добавление схемы для search_path эффективного доверия всем пользователям, имеющим CREATE привилегии в этой схеме. Когда вы запускаете обычный запрос, злоумышленник, способный создавать объекты в схеме вашего пути поиска, может взять на себя управление и выполнять произвольные функции SQL, как если бы вы их выполняли.

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

Чтобы показать текущий путь поиска, используйте следующую команду:

SHOW search_path;

 search_path -------------- "$user", public

Первый элемент указывает, что следует искать схему с тем же именем, что и у текущего пользователя. Если такой схемы не существует, запись игнорируется. Второй элемент относится к общедоступной схеме, которую мы уже видели.

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

Чтобы поместить нашу новую схему в путь, мы используем:

SET search_path TO myschema,public;

(Мы опускаем $user здесь, потому что в этом нет непосредственной необходимости.) И тогда мы можем получить доступ к таблице без уточнения схемы:

DROP TABLE mytable;

Кроме того, поскольку myschema это первый элемент пути, в нем по умолчанию будут создаваться новые объекты.

Мы могли бы также написать:

SET search_path TO myschema;

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

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

OPERATOR(schema.operator)

Это необходимо, чтобы избежать синтаксической двусмысленности. Пример:

SELECT 3 OPERATOR(pg_catalog.+) 4;

На практике обычно полагаются на путь поиска операторов, чтобы не писать ничего столь уродливого.

Схемы и привилегии

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

Пользователю также может быть разрешено создавать объекты в чужой схеме. Чтобы разрешить это, необходимо предоставить CREATE привилегию на схему. Обратите внимание, что по умолчанию у всех есть права на схему CREATE и . Это позволяет всем пользователям, которые могут подключаться к данной базе данных, создавать объекты в ее схеме. Некоторые шаблоны использования требуют отзыва этой привилегии: USAGEpublicpublic

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

(Первый « общедоступный » — это схема, второй « общедоступный » означает « каждый пользователь » .

Схема системного каталога

Помимо public схем, созданных пользователем, каждая база данных содержит pg_catalog схему, которая содержит системные таблицы и все встроенные типы данных, функции и операторы. pg_catalog всегда эффективно является частью пути поиска. Если он не указан явно в пути, то он неявно ищется перед поиском в схемах пути. Это гарантирует, что встроенные имена всегда будут доступны для поиска. Однако вы можете явно указать pg_catalog в конце пути поиска, если предпочитаете, чтобы определяемые пользователем имена переопределяли встроенные имена.

Поскольку имена системных таблиц начинаются с pg_ , лучше избегать таких имен, чтобы избежать конфликта, если какая-то будущая версия определит системную таблицу с тем же именем, что и ваша таблица. (При использовании пути поиска по умолчанию неполная ссылка на имя вашей таблицы будет затем разрешаться как системная таблица.) Системные таблицы будут по-прежнему следовать соглашению о том, что имена начинаются с pg_ , чтобы они не конфликтовали с неполной пользовательской таблицей . имена, пока пользователи избегают pg_ префикса.

Шаблоны использования

Схемы можно использовать для организации ваших данных разными способами. Шаблон безопасного использования схемы не позволяет ненадежным пользователям изменять поведение запросов других пользователей. Если база данных не использует безопасный шаблон использования схемы, пользователи, желающие безопасно запрашивать эту базу данных, будут предпринимать защитные действия в начале каждого сеанса. В частности, они будут начинать каждый сеанс, устанавливая search_path пустую строку или иным образом удаляя схемы, не доступные для записи суперпользователем, из файлов search_path . Есть несколько шаблонов использования, которые легко поддерживаются конфигурацией по умолчанию:

Ограничьте обычных пользователей схемами, приватными для пользователей. Чтобы реализовать это, введите REVOKE CREATE ON SCHEMA public FROM PUBLIC и создайте схему для каждого пользователя с тем же именем, что и у этого пользователя. Напомним, что путь поиска по умолчанию начинается с $user , который разрешается в имя пользователя. Поэтому, если у каждого пользователя есть отдельная схема, по умолчанию они получают доступ к своим собственным схемам. После применения этого шаблона в базе данных, в которую уже вошли ненадежные пользователи, рассмотрите возможность аудита общедоступной схемы для объектов с именами, подобными объектам в схеме pg_catalog . Этот шаблон является безопасным шаблоном использования схемы, если только ненадежный пользователь не является владельцем базы данных или не имеет CREATEROLE привилегии, и в этом случае не существует безопасного шаблона использования схемы.
Удалите общедоступную схему из пути поиска по умолчанию, изменив postgresql.confили создав ALTER ROLE ALL SET search_path = «$user» . Все сохраняют возможность создавать объекты в общедоступной схеме, но выбирать эти объекты будут только полные имена. Хотя квалифицированные ссылки на таблицы допустимы, вызовы функций в общедоступной схеме будут небезопасными или ненадежными . Если вы создаете функции или расширения в общедоступной схеме, вместо этого используйте первый шаблон. В противном случае, как и в первом шаблоне, это безопасно, если ненадежный пользователь не является владельцем базы данных или не имеет CREATEROLE привилегии.
Оставьте значение по умолчанию. Все пользователи неявно обращаются к общедоступной схеме. Это моделирует ситуацию, когда схемы вообще недоступны, обеспечивая плавный переход из мира, не поддерживающего схемы. Однако это никогда не является безопасным шаблоном. Это приемлемо только тогда, когда в базе данных есть один пользователь или несколько взаимно доверяющих пользователей.

Для любого шаблона, чтобы установить общие приложения (таблицы для всех, дополнительные функции, предоставляемые третьими лицами и т. д.), поместите их в отдельные схемы. Не забудьте предоставить соответствующие привилегии, чтобы другие пользователи могли получить к ним доступ. Затем пользователи могут обращаться к этим дополнительным объектам, уточняя имена с помощью имени схемы, или они могут по своему выбору поместить дополнительные схемы в свой путь поиска.

Портативность

В стандарте SQL не существует понятия объектов одной и той же схемы, принадлежащих разным пользователям. Более того, некоторые реализации не позволяют создавать схемы с именем, отличным от имени их владельца. На самом деле концепции схемы и пользователя почти эквивалентны в системе баз данных, которая реализует только базовую поддержку схемы, указанную в стандарте. Поэтому многие пользователи считают, что полные имена на самом деле состоят из . Вот как будет эффективно вести себя PostgreSQL , если вы создадите схему для каждого пользователя. user_name.table_name

public Кроме того, в стандарте SQL отсутствует понятие схемы. Для максимального соответствия стандарту не следует использовать public схему.

Конечно, некоторые системы баз данных SQL могут вообще не реализовывать схемы или предоставлять поддержку пространств имен, разрешая (возможно, ограниченный) доступ между базами данных. Если вам нужно работать с этими системами, то максимальной переносимости можно добиться, вообще не используя схемы.

Блог о починке примусов

Иногда требуется удалить все таблицы в выбранной схеме в базе данных postgresql.

Вы можете сказать — можно удалить сразу всю схему (или еще убойней — всю базу). Но нет, при удалении схемы или базы удалится все остальное, что напрямую не зависит от таблиц. Поэтому просто удалим только таблицы. Для этого нам пригодится следующий запрос, результатом которого будет список запросов на удаление каждой таблицы:

SELECT ‘drop table if exists «‘ || tablename || ‘» cascade;’ as pg_tbl_drop
FROM pg_tables
WHERE schemaname=’public’;

Естественно, вместо schemaname=’public’ нужно подставить вашу конкретную схему.

Выполнив все полученные запросы, получаем схему без таблиц. Однако, может возникнуть ситуация, что в схеме остались последовательности (sequences). Получить все запросы на удаление последовательностей можно таким запросом:

SELECT ‘drop sequence if exists «‘ || relname || ‘» cascade;’ as pg_sec_drop
FROM pg_class
WHERE relkind = ‘S’;

Посмотреть все последовательности (на всякий случай) можно с помощью запроса:

SELECT c.relname
FROM pg_class c
WHERE c.relkind = ‘S’;

И как всегда — при удалении важных данных не забудьте про бэкап.