Может в том проекте подрубил то,что не сделал здесь?

Ну вообще не трудно, но зачем если должен создаваться через sequelize динамически. И по сути, проблему не решает, ибо таблица не одна в проекте

Люди добрые, а как можно получить только один вложенный массив?
Например, {1-electrical-components} или  {1-electrical-components,2-motor-control-and-protection,3-magnetic-contactors}, но не {{}}.


SELECT p.product_id,
      ARRAY_AGG(cv.slugs) FILTER (WHERE cv.slugs IS NOT NULL) AS category_slugs
 FROM products AS p
      LEFT JOIN shop_settings AS ss
             ON ss.product_id = p.product_id
            AND ss.deleted = FALSE
      LEFT JOIN brands AS b
             ON b.brand_id = p.brand_id
      LEFT JOIN categories_view AS cv
             ON cv.category_id = p.category_id
GROUP BY p.product_id;


             product_id                                             |                                                                          category_slugs                                                                          
--------------------------------------------- +-----------------------------------------------------------------------------------------------------------------------------------------------------------------
cc415d6c-02b4-4f1c-b0eb-f50bd436d516    | {{1-electrical-components,2-motor-control-and-protection}}
58bd6c91-8ff5-4b4e-a822-b5bed849986b  | {{1-electrical-components}}
0f69a750-c902-430a-ac11-11f9964d353e    | {{1-electrical-components,2-motor-control-and-protection,3-magnetic-contactors},{1-electrical-components,2-motor-control-and-protection,3-magnetic-contactors}}
nnn                                                                       |
1                                                                           |

А как вы это делали? Не поделитесь опытом?

Нормально ансиблом ПГ апгрейдится безо всякого башизма.

Подскажите тогда как можно идемпотентно вызывать pg_upgrade --check и последующий pg_upgrade. Там же без костылей в виде command (shell тоже не считается) не обойтись. Со всем остальным в целом проблем нет.

> вручную выполнял всё необходимое, перенося каждый шаг в ансибловую роль

вот это то как раз и смущает (( что надо руками дергать почти самые важные команды, регистрировать их выхлоп в переменные и потом городить условные операторы ((

вот все эти ручные команды это и есть "башизм", и это плохо

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

не, ну смотрите, простой модуль file

- name: Change file ownership, group and permissions
  ansible.builtin.file:
    path: /etc/foo.conf
    owner: foo
    group: foo
    mode: '0644'

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

а в случае использования command вылезает императивность и тут явно указывается что и каким образом следует создать - это антипаттерн которым неследует злоупотреблять.

- name: Create file
  ansible.builtin.command: touch /etc/foo.conf

- name: Change group and permissions
  ansible.builtin.command: chmod 0640 /etc/foo.conf

но если писать pg_upgrade роль, то там этих command может быть в большом изобилии, в этом и печаль

башизм это когда баш скрипты дергаются ансиблом, или команды оборачиваются в примитивы ансибла (when, loop и т.п.)

Уже можно говорить что JSON неюзабельный на больших объемах, так как канал забивает. Из-за чего приходится хранить как inflate bytea? ))

А pg_upgrade --check - это на вручную проверить кластер на возможность обновления. В эту ручную проверку не только вот эта команда входит, но и заливка дампа схемы в новую версию.

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