Определение внешнего ключа на основе «динамического» имени схемы

Question

Я знаю, что Postgres позволяет вам определять внешние ключи для схем .

Я использую это в своем мультитенантном приложении, где каждому арендатору присваивается собственная схема. В дополнение к своим собственным таблицам арендаторы также «владеют» некоторыми записями внутри общедоступной схемы, поэтому я могу сделать следующее:

ALTER TABLE tenant_schema.some_table ADD (
  CONSTRAINT workspace_fk
    FOREIGN KEY (workspace_id)
    REFERENCES public.workspaces(id)
)

Таблица public.workspaces выглядит следующим образом:

|--------------------|    |---------------------------|
|  public.workspaces |    | tenant_1642.organizations |
|--------------------|    |---------------------------|
|         id         |    |          id               |
|        name        |    |       workspace_id        |
|     schema_name    |    |        org_name           |
|      subdomain     |    |         address           |
|--------------------|    |---------------------------|

Я использую этот дизайн для маршрутизации веб-запросов в соответствующую схему на основе субдомена. Например, если кто-то отправляет запрос на https://org1.fancyapp.com/resource/id, я могу выполнить поиск по org1 в разделе «public.workspaces», а затем узнать, направить ли этот запрос на «schema_org1.sessions», чтобы проверить, является ли его файл cookie сеанса действительным.

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

Мои вопросы:

1. Если tenant_schema отбрасывается с помощью DROP SCHEMA -schema- CASCADE (что я и делаю, когда кто-то отменяет свою подписку и удаляет свою учетную запись), узнает ли Postgres об автоматическом удалении связанной записи в public.workspaces?

2. Как связать рабочее пространство с записью в tenant_schema.organizations? Другими словами, как я могу добавить внешний ключ (например, organization_id) в public.workspaces так, чтобы отношение определялось динамически на основе значения в столбце schema_name?

Есть ли способ динамической интерполяции значения столбца при определении отношения внешнего ключа? например,

ALTER TABLE public.workspaces ADD (
  CONSTRAINT organization_fk
    FOREIGN KEY (organization_id)
    REFERENCES ${public.workspaces.schema_name_col_value}.organizations(id)
)

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