Добрый день. В Windows, в Установке и удалении программ есть информация о издателе приложения, пример на скрине. Есть ли что-то более информативное, чем select version() чтобы узнать информацию о версии/билде, издателе и тд?

А есть ли какой-то способ получить одновременно seqmin, seqmax последовательности и ее last_value, не прибегая к execute?

То есть одним запросом вытянуть эти параметры для всех последовательностей в базе

Самая жирная будет при отображении пользователю его тикетов.

Свой путь начинаем из талицы ticket, далее заходим в ticket_ticket_status и получаем последний статус, потом ticket_manager чтобы узнать кто занимается нашим тикетом.

Добрый день.
Вопрос:
существуют ли адекватные системы контроля версий специализированные или адаптированные под PG?

DCVS ?
Или вообще миграции ?

... ну обычно люди берут liquibase

ну вот я только ее и нашел. фактически, альтернатив не увидел. интересно было, что народ для этих нужд используют. спасибо

Как мигрировать данные с PostgreSQL 13 в PostgreSQL11.8?
Дамп снятый с помощью pg_dump версии 11.8 не подходит для 13. Ругается.

Могу ли я устновить бинарник pg_dump от PostgreSQL 13?

Ну я то обычно в своих проектах себе прогон миграций пишу руками при старте приложения - так проще версионирвать так как не нужна таблица локов.
В целом очень сильно зависит от того как реализован CI/CD конкретных приложений и есть ли соответсвующие операторы.

старый дамп на новой базе может не сработать, поэтому надо использовать 13-й pg_dump
а дальше руками править то, что не поинмает 11-й Postrges.

увы, в обратную сторону совместимости нет (и я бы не рассчитывал).

Можете, обычно пакуют по мажорным версиям.

Смотря на что ругается...

Пробуйте pg_dump --schema-only - там видно будет каких фичей нет в 11.8 от них уже будете отталкиваться...

Поскольку ticker_id для нас константа, я бы делал так:
1. SELECT FROM  ticket_manager WHERE ticket_id [ORDER BY created_at FETCH FIRST 1 WITH TIES]
2. SELECT FROM ticket_ticket_status WHERE ticket_id
3.1. SELECT ticket_message JOIN user WHERE ticket_id, если у вас менеджер - тоже пользователь, или просто SELECT ticket_message т.к. автор заявки и так всё про себя знает.
3.2. собираете уникальные ticket_message_id из 3.1 и делаете SELECT FROM ticket_message_attachment

Не знаю как вы, а я вижу только один JOIN, с ним любая база справится на счёт "раз".

Если не использовать какой-то странный функционал - не должно быть проблемой.
Бинарной совместимости действительно нет, так как менялся протокол.

Опа, вот это прикольная тема.

@YuriyYarosh Спасибо за ответы.  Будем в тему плотнее окунаться, пощупаем liquibase для начала. По поводу ситуативности, конечно, понятно.

Спасибо большое за ответ!

Просто люди обычно в liquibase на голом SQL чаще пишут - так проще использовать более-менее актуальный функционал

Всякие XML / YAML сейчас редко используются из-за отсутствия поддержки фичей конкретно постгреса...

flyway ещё есть, плюс/минус то же самое

еще есть sqitch