Привет! Прошу совета! Написал вьюху в postrgress сохранил ее. А

когда открыл код изменился. Выводит тоже, но в коде изменилась кодировка. Как мне открыть мой старый код? Спасибо

Никак, думайте почему так произошло и старайтесь избегать.

А что могло произойти, например? Ранее делал тоже самое в ms sql ни с чем подобным не сталкивался

Ага напишите в коде юникод, для ms, я на вас посмотрю

А как именно изменился? В SQL существуют альтернативные синтаксические конструкции, позволяющие выразить одно и то же и PostgreSQL при построении дерева запроса производит приведение таких альтернативных синтаксисов к одному представлению, возврат из которого к текстовому запросу однозначный и не всегда соответствует исходному синтаксису. Например, xxx in (1,2,3) превратится в xxx = any(array[1,2,3]).

In заменились на array, кириллица на 344/433/444, а * на полный набор столбцов в таблицах

Есть ли возможность создавать представления так, что мой код не менялся?

нет

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

По поводу кириллицы - разбирайтесь с кодировками или используемым клиентом (мб. он криво с ними работает), остальные изменения синтаксический эквивалентны. Или вы ожидали, что при добавлении нового поля в таблицу, оно появится и во view? Так не бывает (разве что создавать event trigger, в котором пересоздавать view, при чём через drop). У view фиксированный набор колонок, т.к. вместо с самим представлением создаётся тип данных.

Я использую клиент dbeaver. Какой вы посоветуете использовать?

Храните код в системе контроля версий, а не в СУБД. PostgreSQL не хранит код (кроме кода хранимок) и не предназначен для этого. В остальном view превосходны для решения задачи "вот этот хитрый подзапрос надо использовать в 100500 других запросов и не охота его каждый раз писать".

view выполняют ровно такую же функцию, как вы описали, и в других РСУБД, но только ПГ смеет исказить мой код до неузнаваемости. Я понимаю, что это требуется, в частности, для типизации структур данных, но такое поведение всяко странно, особенно при опыте работы с другими рсубд (oracle, mssql, уверен, что большинство других)

Set client_encoding несовпадает с тем, что реально передавалось на скрвер. Или всё совпадало, но часть символов отсутствует в указанной кодировке, и клиент перекодировал как мог. Наконец, с client_encoding всё в порядке, однако кодировка базы не имеет необходимых символов.

Нет.

create or replace view testview as select 'кириллица' cyr; в dbeaver 21.0.5 отображается как (создавал в нём же): CREATE OR REPLACE VIEW report.testview AS SELECT 'кириллица'::text AS cyr;

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

У меня вместо ::text '\320\272\320' и т.д

Сообщество наверняка откажэтся. Поскольку видно много работы _ и не видно никаких плюсов.

Можно попробовать заказать данную доработку, если это принципиально прям, тут вопрос в том, примут ли патч.

Подозреваю, что нет: если делать подобный патч, он должен распространяться на другие объекты, а не только view. А это увеличит размер pg_catalog

А также потому, что запрос может перестать соответствовать представлению (тот же select *)

Много работы дажэ не столько в переписывании каталога — сколько в обеспечении сквозной совместимости со всем, что есть.