Нет звука в трансляции

If the WITH ORDINALITY clause is specified, an additional column of type bigint will be added to the function result columns. This column numbers the rows of the function result set, starting from 1. (This is a generalization of the SQL-standard syntax for UNNEST ... WITH ORDINALITY.) 

> ...некоторые считают...

Я извиняюсь, но с чего по этому тексту кто-то может предположить, что следует порядок? Когда чего-то не написано явно, из этого следует, что может быть и так и сяк, то есть порядок просто не определен. Тут просто нет двоякого толкования.

ф-ция unnest работает для массивов и для tsvector (см `\df unnest`). оба этих типа основаны на порядке элементов.
т.е. вы можете, конечно, считать, что массив – это просто куча. но т.к. у элементов массива есть вполне себе осознанная нумерация, то все ф-ции, которые работают с массивами, соблюдают порядок. иначе вы не можете никак ожидать, скажем, что array_agg() при одном и том же отсортированном входном наборе будет возвращать одно и тоже.
или как по вашему работает FOREACH elem IN ARRAY конструкция в PL/pgSQL — там же нет никакой явной сортировки!

посмотрите на такой пример:

SELECT ('[5:7]={1,2,3}'::int[]), array_prepend(10, ('[5:7]={1,2,3}'::int[])), array_cat(('[5:7]={1,2,3}'::int[]), '{10}');

не смотря на то, что индексация в изначальном массиве начинается не с единицы, ф-ции сохраняют порядок элементов.

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

- можно залезть в код и убедиться: https://github.com/postgres/postgres/blob/1c1cbe279b3c6e8038c8f8079402f069bb4cea4c/src/backend/utils/adt/arrayfuncs.c#L6038
- можно написать в pgsql-docs@postgresql.org и попросить добавить разъяснения в таблицу 9.52 о том что порядок записей в выводе unnest соответствует порядку элементов в массиве

SELECT ('[5:7]={1,2,3}'::int[]), array_prepend(10, ('[5:7]={1,2,3}'::int[])), array_cat(('[5:7]={1,2,3}'::int[]), '{10}');

>> скажем, что array_agg() при одном и том же отсортированном входном наборе будет возвращать одно и тоже.

нужно понимать разницу между array_agg() и unnest(), первая возвращает структуру данных, которая уже обладает порядком (массив), который задан выражением order by внутри агрегата, вторая же функция возвращает структуру данных с неопределённым порядком (result set, как вы выразились)

>> или как по вашему работает FOREACH elem IN ARRAY конструкция в PL/pgSQL — там же нет никакой явной сортировки!

это не SQL уже

>> посмотрите на такой пример:
>> SELECT ('[5:7]={1,2,3}'::int[]), array_prepend(10, ('[5:7]={1,2,3}'::int[])), array_cat(('[5:7]={1,2,3}'::int[]), '{10}');
>> не смотря на то, что индексация в изначальном массиве начинается не с единицы, ф-ции сохраняют порядок элементов.

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

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

после того, как вы на выходе получили result set нет никакой семантики массива, просто потому что это уже не массив. За ссылки спасибо

> вторая же функция возвращает структуру данных с неопределённым порядком

с чего бы это? посмотрите что на вход принимает unnest.

А какая разница, что приходит на вход?

такая, что unnest — специализированная ф-ция для работы с массивами.

Это конечно о многом говорит)))

Компания: Bell Integrator ищет в свою команду разработчика PostgreSQL для участия в проекте разработки корпоративного хранилища данных в одном из крупнейших российских банков. В рамках проекта предполагается внедрение КХД и интеграция со сторонними системами.
Задачи:
 • Разработка механизмов КХД на     PostgreSQL;
 • Внедрение КХД
Основные требования:
 • Экспертное знание PL/pgSQL;
 • Экспертное знание SQL, опыт написания и оптимизации сложных запросов;
 • Опыт создание хранилищ данных «с нуля»
Будет плюсом:
 • Опыт тюнинга PostgreSQL,Greenplum/ArenaData
 • Опыт работы с другими СУБД (Oracle,MS SQL, DB2 и тд).
 • Знание банковской предметной области, опыт работы разработчиком в банке
 • Опыт работы хотя бы с одним из ETL-инструментов (Oracle DI, Informatica PC, IBM Data Stage, Talend DI)
 • Опыт работы хотя бы с одним BI-средством ( Cognos, PowerBI, Tableau и тд)
Условия работы
 • Реализация эффективных сервисов, значимых как для бизнеса, так и для пользователей;
 • Возможность профессионального и карьерного роста в компании, возможность поучаствовать в разных проектах;
 • Опыт работы в распределенной команде профессионалов;
 • Уровень заработной платы до 200net;
 • Удаленная работа на время пандемии, далее локация в Москве (м. Китай город)

Контакты: @AnechkaSon

Ну а многие предполагают, я так понимаю...
Если смотреть совсем уж формально, то похоже, что не следует (или, может, я плохо понимаю по-английски... или не только я).
В любом случае, слишком налегать на формализованные определения тоже не стоит — а то получится как местами в том же стандарте — сильно формализовано, ничего непонятно, а иногда, несмотря на всю "точность" — просто неправильно. ;)
Опять-таки, можно же написать в -docs / -general — спросить у англоговорящих людей, достаточно ли это однозначно написано на самом деле или нет.

Суть моих вопросов не в буквоедстве, а в том, чтобы понять логику тех, кто интерпретирует по-другому. Я так понимаю, что все сводится к "ну это же функция для работы с массивами"

SELECT ('[5:7]={1,2,3}'::int[]), array_prepend(10, ('[5:7]={1,2,3}'::int[])), array_cat(('[5:7]={1,2,3}'::int[]), '{10}');

(Побуду адвокатом дьявола) Ну а если меня всё это не убеждает? ;)
Т.е. у массивов-то есть нумерация, а вот у result sets нет порядка. Где в документации PostgreSQL явно указано, что результат Set-Returning Function от массива должен как-то относиться к порядку его элементов? Опять-таки, где указано, что порядок rows, возвращаемых SRF, не может быть изменён до применения к ним ORDINALITY?

Их логика, скорее всего, сводится к тому, что они читали стандарт (когда реализовывали unnest и вообще SRF), и теперь для них это "очевидно".
Поэтому я ранее и писал, что в документации всё-таки недостаточно подробно описываются такие вещи.

Интересный вопрос как это описать в дткументации) вот все result set ы не имеют порядка кроме вот этого. Так чтоли? Или как это в стандарте описано?

А стандарту удаётся донести эту простую мысль, причём только для unnest (ORDINALITY для других SRF — это вообще postgres-овское расширение стандарта, насколько я помню) "всего лишь" на трёх страницах, с привлечением нескольких промежуточных определений, в том числе через рекурсивные запросы (я совсем не шучу).

Блин, ну скиньте мне пожалуйста, я голову поломал, не могу найти тот драфт. Ссылки не работают уже

Только что открыл www.wiscorp.com/sql20nn.zip из той ссылки, которую ранее приводил — что, у Вас не работает?
Там во второй части, 7.6 <table reference> (начинается на стр. 348), можно читать с 7 пункта.

всем привет вопрос как понять что дамп бд встал нормально?

Да гон какой-то, днем много раз пытался. Эта ссылка гуглилась, но не скачивалась. Сейчас качается 🤷‍♂

Странно... но ладно, работает и хорошо.
И, кстати, ORDINALITY для всех остальных функций — чисто postgres-овская возможность.
В стандарте:

<collection derived table> ::=
UNNEST <left paren> <collection value expression>
[ { <comma> <collection value expression> }... ] <right paren>
[ WITH ORDINALITY ]

и всё.