Варианты версий PostgreSQL для обратной совместимости?

Question

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

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

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

Есть ли известная передовая практика для «обмена имен» схемы «интерфейс» в соответствии с версией БД?

В качестве альтернативы, существует ли лучший способ поддерживать обратную совместимость?

Answer 1

Есть ли известная передовая практика для «замены имен» схемы «интерфейс» в соответствии с версией БД?

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

Вид BC имеет RULE или (в более новых версиях PostgreSQL) а DO INSTEAD триггер со ссылкой на текущей версии таблицы явно из его нормальной схемы, например public.People для поддержки записи, если это необходимо.

Это работает только в том случае, если вам нужен BC на основе входа для каждого пользователя, где вы можете ALTER USER ... SET search_path или (что менее вероятно), где вы можете установить приложение, которому требуется BC, для выполнения команды SET search_path для каждого сеанса.