Коллеги, где можно скачать ISO SQL стандарт в pdf? Не

платить же больше сотни баксов за скачивание на оф сайте

Пытался найти, безуспешно. Только за 100 баксов

Можем скинуться, если надумаете)) Мне тоже нужен

Если нужны новые официальные документы — придётся платить. :( До 2011 включительно есть общедоступные drafts. А Вам зачем, кстати?

Да вот приходится писать доку одну по архитектуре и не понятно, могу ли я указать, что это часть SQL стандарта или нет. Нужно сам стандарт посмотреть, чтобы ответить, а его и нет. Я на 99% уверен, что таблицы, индексы есть в стандарте, вопрос в какой степени они там описаны. И по другим объектам тоже вопрос, какие “стандартные”, а какие нет

https://webstore.iec.ch/preview/info_isoiec9075-1%7Bed5.0%7Den.pdf Оно?

чё-то маловато)

Не нужен Вам стандарт для этого (и Вы очень зря думаете, что, если бы у Вас был стандарт, Вы могли бы отвечать на подобные вопросы.) ;) Я к чему... Вы предыдущие версии стандарта видели когда-нибудь? Так вот лучше он не стал. :( А так — см. https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL_Standard

Кстати: > индексы есть в стандарте Индексов вообще нет в стандарте, никаких.

блин, точно, читал когда-то об этом, но почему-то из памяти выпало. А какие типы объектов стандарт покрывает, вы не знаете? Соглашусь, что целиком его прочитать сложно и не нужно, но справочно использовать почему бы и нет? Драфт (какой-то из) я видел когда-то и обращался к нему как раз чтобы понять, что сказано в стандарте, потому что в доке по pg не был описан интересовавший меня случай

Да он много чего покрывает — Вы конкретнее спрашивайте. Опять-таки, см. ссылку. > но справочно использовать почему бы и нет? Потому что неподготовленный к длительным страданиям человек вряд ли поймёт, что написано в большинстве его разделов. > я видел когда-то и обращался к нему как раз чтобы понять Если действительно поняли — Вам повезло (что удивительно, иногда авторы переходят на нормальный английский, и уж совсем редко даже дают однозначные описания — видимо "И у Мастера бывают ошибки" ©). > pg не был описан интересовавший меня случай Какой, кстати? Если его нет по приведённой ссылке — есть люди, заинтересованные в том, чтобы добавить. ;)

Ну о мнениях спорить бесполезно, ваше мнение, что смотреть бесполезно, ок, тут дело хозяйское, я бы посмотреть не отказался) Про тот случай, если мне память не изменяет: select … from unnest(…) with ordinality вот в этом случае будет ли ordinality совпадать с порядком элементов в массиве? Эмпирически в pg (на тот момент 9.6) совпадало всегда, но в доке по pg не было на что опереться, чтобы удостовериться, что так задумано. Мы ради инетереса смотрели стандарт и там тоже ничего не было по этому поводу, откуда заключили, что это ненадёжно и надо от этого избавиться

> Ну о мнениях спорить бесполезно, А давайте поспорим. ;) > вот в этом случае будет ли ordinality совпадать с порядком элементов в массиве? Да, будет. И это однозначно указано в стандарте. > Мы ради инетереса смотрели стандарт и там тоже ничего не было по этому поводу Т.е. было. > что это ненадёжно и надо от этого избавиться И сделали неправильный вывод. <sarcasm>И что, полезно для вас оказалось чтение стандарта, да?</sarcasm>

Здорово, значит ошиблись. Значит тем более надо ещё раз взглянуть на этот стандарт и разобраться, потому что в доке по pg этого нет. Получается только в стандарте

Я это всё писал к тому, что чтение ISO SQL — это специальный навык, не иначе. :( Вот "вы" (несколько человек, я так понимаю?) читали, и даже не нашли, где это, я так понял (пункт 7.6 <table reference>, начиная с подпункта 7 в SQL:2011)? И сделали совершенно неправильный вывод! Т.е. лучше в спорных случаях обращаться к тем, кто этим навыком владеет — например, сразу спрашивать в postgresql-general или -hackers (и даже так не факт, что Вы услышите одну интерпретацию — вот настолько "прекрасно" написан стандарт). > потому что в доке по pg этого нет. Да, вот зря некоторые [подобные] вещи туда не вносятся. Можете написать в -docs (я уже не в первый раз слышу, что кто-то сомневается про ORDINALITY, кажется).

Мне сейчас чтобы на ваши вопросы ответить, надо этот драфт найти, который уже на оф сайте не доступен. На память я конечно-то же не помню какой раздел подпункт и т.п. У вас он(драфт), похоже, есть? А то, что не нашли или недополняли, плохо, конечно, надо разобраться, почему. Этому же не то, чтобы невозможно? У вас же получилось разобраться, почему у других не получится, пусть даже не сразу?

вот тут дока говорит, что вывод нумеруется в порядке выдачи значений ф-цией: https://www.postgresql.org/docs/13/queries-table-expressions.html#id-1.5.6.6.5.9.2

На что можно придумать возражение вроде "ну там же не написано, что PostgreSQL не может произвольно переупорядочить function result set перед нумерацией". ;) Оно, может, кажется смешным... но мне помнится, что кто-то тут что-то подобное на самом деле писал.

А вот resultset функции сам по себе обладает свойством упорядоченности?

resultset не функция, а термин. база не будет упорядочивать что попало, это же дорогая операция — сортировка

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

значит нет никакого порядка выдачи значений? То есть он физически-то есть по факту, но не опреден заранее. Так?

зависит от типа данных, нет? если мы говорим про массивы, то у них порядок определён по определению

> У вас он(драфт), похоже, есть? Да, это самое новое, что есть в открытом доступе. https://wiki.postgresql.org/wiki/Developer_FAQ#Where_can_I_get_a_copy_of_the_SQL_standards.3F > надо разобраться, почему. Да потому что стандарт написан в основном отвратительно, вот и всё. ;( > Этому же не то, чтобы невозможно? Иногда это именно так. Кардинальные различия в реализации некоторых вещей в разных СУБД (каждая из которых считает, что соблюдает стандарт), как бы намекают нам (как и случаи, когда на трёх читающих одни и те же страницы получается четыре разных, правдоподобных мнения). ;) > У вас же получилось разобраться, почему у других не получится, пусть даже не сразу? Потому что это там ещё относительно нормально написано.

Нет, Вы тут уже "съехали" в будет / не будет (выгодно ли это) и т.п. ;) А вопрос-то о правильности, о гарантиях, "отныне и впредь".

Сойдёмся на этом) стандарт написан отвратительно и сложен для понимания.

не отменяет того, что resultset — термин.

у массива порядок может и определен, а у result set-а, который возвращает функция?

Термин. Но, возвращаясь к первоначальному вопросу: > select … from unnest(…) with ordinality вот в этом случае будет ли ordinality совпадать с порядком элементов в массиве? Как видите, некоторые считают, что из: 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.) такой вывод (что всегда будет) не следует. Т.е. документация PostgreSQL написана неоднозначно / непонятно.

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

ф-ция 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 соответствует порядку элементов в массиве

>> скажем, что 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.

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

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

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

(Побуду адвокатом дьявола) Ну а если меня всё это не убеждает? ;) Т.е. у массивов-то есть нумерация, а вот у 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 ] и всё.

Я, кажется, понял в чём проблема. По стандарту (тому драфту), unnest это не функция даже, а просто специальная синтаксическая конструкция, со своей собственной семантикой, которая из коллекции позволяет сделать таблицу. И там специально указано, что в случае с multiset не может быть никакого ordinality, что логично, ибо неопределённый порядок никому не нужен. А вот если не multiset, т.е. array (потому что других типов коллекций не определено в стандарте), то уже ordinality имеет смысл и задаётся через рекурсивный запрос. Кудрявенько конечно описано, без поллитры не разберёшься. Спасибо, что подсказали, куда копать)

Да не за что! ;)

https://git.postgresql.org/pg/commitdiff/662affcfe9

Хмм... и вот, к вопросу о том, насколько хорошо мы понимаем английский: I think 7.2.1.4 is clear enough: 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. Им-то виднее, мне кажется. А вообще — документацию улучшили, приятно. :)

Это я завтра ещё хочу спросить про остальные табличные функции. Не только же unnest есть. Для многих других функций тоже порядок в доке прописывать?

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

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

Наверно. Но есть ещё как минимум одна функция, в доку по которой тоже стоит добавить упоминание про порядок - jsonb_to_recordset

Если нет, то у меня возникнет вопрос "почему" )

Формально может быть предложена оптимизация для больших jsonb с параллельным выполнением функции)))

Да может, но хочется, конечно, чтобы семантика массивов и в json-е сохранилась. А кстати, для обычных массивов тоже такой аргумент мог бы быть?

По мне да. Именно поэтому я не считаю with ordinary в стандарте как упорядоченный из «сути» а не буквы)))

Для unnest — не мог бы (обсуждали уже). Опять-таки, Tom почему-то считает, что написанного достаточно. Либо он не понял, о чём именно спрашивали, либо ему виднее. ;)

фокус смещён в плоскость claim that the spec says that ordinality matches the array indexes, а не к упорядочиванию результатов ф-ции. т.е. да, просится уточнение про другие ф-ции для которых _ожидаются_ нужный порядок. в том 9.16 есть примеры ( в таблице 9.47 ) для jsonb_object_keys или jsonb_to_recordset

А, в этом смысле да. Но такие массивы — расширение стандарта, поэтому всё равно. А в чём вопрос с последними двумя? Они-то никакого порядка не гарантируют сами по себе.

> Они-то никакого порядка не гарантируют сами по себе. да-а-а… извините, поспешил.