возможно проблема из-за того что оригинальная БД postgres 11, в то время как у меня 12

Я бы в psql всё это проверил, на Вашем месте. Потому что, опять-таки: https://t.me/pgsql/235610

ок, спасибо за советы

Если "проблема" в этом — опять-таки, это может быть только проблемой клиента (Intellij Idea). ;)

Я, во всяком случае, в первом выводе из изначальной базы не узнаю представленный формат представления bytea. Это не escape, не hex. Даже на base64 не похоже какой-нибудь. Похоже на самодеятельность IDE.

там может быть проблема в том что я к той БД через ssh тунель подключаюсь, и какие нибудь переменные неправильно не передаются

Ребята, спасибо за помощь, в принципе дали информацию куда копать

Можно для уверенности попробовать select get_byte(field_name,0) сделать и посмотреть что вернёт - ascii номер символа '\' или содержимое первого байта, каким оно и должно быть (в скриншоте у первой строки это '4' например)

Если первое - косяк импорта. Если второе - просто проблемы с представлением

Всем привет. Можно ли при подсчете агрегирующих функций нескольких (COUNT, ARRAY_AGG) задавать в FILTER условие для количества связанных записей в "дочерней" таблице и обойтись без повторяющихся вложенных запросов в FILTER?

А что будет, если я на реплике включу archive_mode = on и задам archive_command? Будут писаться архивы?

нет, не будут

для реплики нужно archive_mode = always

Это для каскадной репликации?

Спасибо!

Коллеги, а есть какие-то простые и проверенные решения для того чтобы в GIT сохранять историю изменений в базе?
Хочется, чтобы вместе с коммитом кода фичи можно было коммитить изменения и БД (структуры таблиц, view, функции).
При этом интересует даже не DDL с diff, т.е. не версифицирование структуры. Можно прямо скрипты создания для каждого объекта.

Самый простой вариант - это как-то экспортировать структуру БД в файл, и засунуть с коммитом в GIT. Это можно сделать с pg_dump. Но одним файлом это не удобно, изменения не удобно потом  смотреть. Удобнее было бы каждую сущность в отдельный файл.
Может есть какие-то готовые скрипты?

Вручную написанные миграции люди в гит кладут.

Целевая задача не миграция.

Представьте себе, в GIT лежит всегда актуальный набор скриптов для разворачивания базы. А история коммитов позволяет по каждой сущности видеть изменения и связь с фичами.

Разработчик вносит изменения в тестовую базу. Потом прогоняет скрипт, выгружает структуру базы и прислюнявливает к коммиту с кодом фичи. Конечно, есть ограничение, чтобы два разработчика не вносили изменения одновременно в одни и те же сущности, но в рассматриваемой задаче такого точно нет.

Вообщем это не замена скриптам миграции и на версионифицированею самой структуры.