Что вернет запрос с оконной функцией sum over(order by)

Что проверяют

Понимаете ли вы, что оконная функция считает значение для каждой строки и не схлопывает результат, и знаете ли про рамку окна. Тут же проверяется, читали ли вы про порядок вычисления запроса, и умеете ли вы принять результат в Go без потери точности.

Как отвечать

SUM(x) OVER (ORDER BY y) это накопительный итог: строк остаётся столько же, к каждой добавляется сумма по всем строкам от начала окна до текущей.

select id, amount,
       sum(amount) over (order by id) as running_total
from sales;

Главное, что отличает сильный ответ: ORDER BY без явной рамки означает RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, а RANGE работает по равным значениям ключа сортировки. Если у нескольких строк одинаковый id, все они получат одну и ту же сумму, включающую их все. Построчное накопление даёт только явная рамка ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW.

Дальше стоит добавить:

• без ORDER BY рамкой становится всё окно, и сумма одинакова во всех строках, то есть получается агрегат рядом с детализацией;
• PARTITION BY перезапускает накопление внутри каждой группы;
• оконные функции считаются после WHERE, GROUP BY и HAVING, поэтому отфильтровать по накопительной сумме в WHERE нельзя, нужен подзапрос или CTE.

В Go смотрите на тип: сумма по integer в PostgreSQL возвращается как bigint, а по numeric как numeric, и драйвер отдаёт её строкой или байтами, а не float64.

Где спотыкаются

Ждут строго возрастающий столбец, а на дублях ключа сортировки видят повторяющиеся значения, и объявляют это багом СУБД. Это рамка RANGE по умолчанию.

Пытаются написать where running_total > 100 и получают ошибку про неизвестный столбец: алиас окна недоступен на этапе фильтрации.

Считают, что OVER это замена GROUP BY, и мешают их в одном запросе не думая: оконная функция применяется уже к сгруппированному результату, а не к исходным строкам.