так работают последовательности, это нормально

можно, но для вывода номера позиции в запросе используется другой механизм

Хорошо,а как конкретно Вы используете массивы  ?

- в прикладных запросах для временной аггрегации каких-то данных
- при анализе данных: через массивы удобно собирать информацию в рамках одного запроса
- в таблицах, когда там массив необходим (например, приходит N чисел с датчика при замере)

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

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

мне кажется, что вы пытаетесь родить не-реляционный подход в реляционной базе. не надо так. либо возьмите специализированную не-реляционную базу (где есть объект, доступный по ключу), либо займитесь проектированием реляционной модели хранения данных

Всем привет!
скажите где не прав

SELECT DISTINCT 
tnved "ТН ВЭД 6 знаков", 
tnved_name "Описание ТН ВЭД",
apk_prom "Отрасль (пром/апк)",
indystry "Категория",
(select sum(stoim) from public.data_fts_test0 as SubData where SubData.tnved = DataFts.tnved and napr = 'ЭК') AS "Объем экспорта, долл. США",
(select sum(stoim) from public.data_fts_test0 as SubData where SubData.tnved = DataFts.tnved and napr = 'ИМ') AS "Объем импорта, долл. США",
EXTRACT(YEAR FROM period_date) AS "Год"
FROM  public.data_fts_prod as DataFts
GROUP BY tnved, tnved_name, apk_prom, indystry, "Год"
;

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

массивы можно использовать только там, где их элементы не являются реляционной сущностью. Например, для хранения каких-нибудь RGB цветов, битовых карт, и тд. В примере выше - являются сущностью и используются для группировки другой сущности. Это грабли и большая ошибка, которая будет иметь тяжелые последствия, тем более если это реальный проект, а не учебный. Даже если закрыть глаза на кривость и неудобность такого решения, в реальных проектах нет никаких "да вот оно щас один раз загрузится и всё". Это сейчас не надо, а через 10 лет будет надо. Реляционную алгебру не просто так придумали. За такое такое проектирование можно легко схлопотать увольнение, потому что специалист по рсубд обязан это знать.

Это вы про мой пример?!)

не, я про ту картинку

SELECT DISTINCT 
tnved "ТН ВЭД 6 знаков", 
tnved_name "Описание ТН ВЭД",
apk_prom "Отрасль (пром/апк)",
indystry "Категория",
(select sum(stoim) from public.data_fts_test0 as SubData where SubData.tnved = DataFts.tnved and napr = 'ЭК') AS "Объем экспорта, долл. США",
(select sum(stoim) from public.data_fts_test0 as SubData where SubData.tnved = DataFts.tnved and napr = 'ИМ') AS "Объем импорта, долл. США",
EXTRACT(YEAR FROM period_date) AS "Год"
FROM  public.data_fts_prod as DataFts
GROUP BY tnved, tnved_name, apk_prom, indystry, "Год"
;

Можно сделать через join но все зависит от ваших данных и наличия индексов

да пёс его знает, может я в чём-то и не прав. С этим куском данных нет никакой работы, добавлений или модификаций, его только раз прочитать и всё. Просто он выстраивается в иерархию/структуру, а тут оказывается сразу можно упаковать через составной тип в массив и отправить готовый к чтению json.  Такой себе слепок объекта класса "задние"
Очень удобно....
А основная работа ведётся с другой таблицей, там уже и обновление и добавление записей, отношение с другими таблицами "один ко многим" и т.д. .... модель

надо. Кто-то будет менять или анализировать эту структуру. Нельзя так рассуждать.

Это мышление "сделаю так (json) потому что так проще вернуть результат" - в корне неверный подход, представление и сериализация данных - это отдельный от хранения и обработки данных процесс.

Люди и компании потом теряют огромные деньги на рефакторинг такой дичи

Собственно все о чем мы говорим - это несколько глав любой книги по рсубд, там очень подробно указано, почему так делать нельзя, с примерами аномалий, и тд. Очень рекомендую изучить матчасть.

Такие данные действительно меняются, сериализация для передачи или временное хранение состояния какой-то сущности. А тут то этого нет, как часто Вы видели, чтобы стадион перестраивали. Здесь благодаря составному типу всё добавляется одной командой, то есть гибкость и рефакторить нечего

Да я могу кучу примеров придумать когда понадобится это переделать. Переделка стадиона, переформатирование тарифов секторов, перенос ПО на другой стадион, и тд и тп. Нельзя так рассуждать, это преступление. Это ты думаешь что не надо, совсем не значит что на самом деле никогда не будет надо. Надо соблюдать стандарты и правила создания баз данных, вот что надо.

Очень правильные слова говоришь.

Одно плохо - зря.
Они все равно не поверят, пока их самих жизнь не научит

Я просто люто ненавижу тех кто так делает, но обычно я работаю с продуктом их труда, а тут вот живой :)