Ограничения в другой схеме - PullRequest
0 голосов
/ 01 мая 2018

Экспериментируя с представлениями information_schema.*, я узнал, что ограничения могут быть определены в другой схеме. Это отражено в представлении information_schema.table_constraints, которое добавляет столбец, такой как constaint_schema, для обозначения этого:

select * from information_schema.table_constraints

constraint_catalog | constraint_schema | constraint_name | table_catalog | table_schema | table_name | constraint_type | is_deferrable | initially_deferred 

Для внешних ключей это имеет смысл: можно ссылаться на таблицу в другой схеме.

Теперь мне интересно, применимо ли это и к другим ограничениям. То есть возможно ли, что основное, уникальное или проверочное ограничение определено в другой схеме как схема, в которой определена таблица? В каких случаях constraint_schema будет отличаться от table_schema в information_schema.table_constraints?

1 Ответ

0 голосов
/ 02 мая 2018

https://www.postgresql.org/docs/current/static/sql-createindex.html

индекс всегда создается в той же схеме, что и его родительская таблица

https://www.postgresql.org/docs/current/static/ddl-constraints.html

Добавление уникального ограничения автоматически создаст уникальное B-дерево индекс для столбца или группы столбцов, перечисленных в ограничении.

и

Добавление первичного ключа автоматически создаст уникальный индекс B-дерева на столбец или группу столбцов, перечисленных в первичном ключе

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

...