Некая система сериализует свои данные в таблицы PostgreSQL. Таблицы связей не имеют (разумеется можно в запросах связывать, для этого препятствий нет). Если изменяется структура сериализуемых данных для одной из таблиц (добавились поля, пропали поля, изменился тип поля и тд), система создает таблицу с таким же именем как и прежняя  с припиской окончания tmp и наполняет ее данными. По окончании синхронизации происходит переименование старой в *old а *tmp в оригинальное имя (без tmp). 
Для последующей работы с данными требуется писать view. Получили проблему - при автоматическом переименовании таблиц связи view убегают своими ссылками в старую таблицу *old. Выяснилась особенность Postgre - ссылаться по OID, а не по имени таблицы. В итоге представление продолжает использовать данные не актуальной таблицы. Вторая проблема - со временем таблицу *old при очередной итерации предстоит удалить, а у нее есть связи. Но это решается радикально каскадным удалением.
Есть ли какое-то решение? Как перестроить ссылки из View на новую таблицу с таким же именем как и в первой несмотря на то, что OID у нее теперь другой? Разумеется это убережет view и от каскадного удаления 

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

эмм... пересоздать view это половина дела, а как поймать новый oid, который система присвоила пересозданной таблице (которая была создана как "что-то-там-такое_tmp" и по готовности после полного заполнения превратилась просто в "что-то-там-такое" и заняла место прежней одноименной таблицы (а oid стал другим)?

Так представление при пересоздании оперирует именами, а не идентификаторами. Так что при пересоздании представления таблица будет опознана по имени, и в формализованное представление будет помещён её актуальный на момент пересоздания oid. Как-то я не понимаю сути проблемы...