Не "неопределённый результат", а результат LIMIT-а, кторый применён к rows, отсортированным в произвольном порядке. Т.е. если у Вас, например, есть: "... LIMIT 3;" и без LIMIT возвращается больше трёх rows, возрат двух — это, безусловно, bug в СУБД. И ещё раз, здесь Вам не C. ;)

Ну не знаю, Ярослав. Для меня "unpredictable subset of the query's rows" - это "неопределённый результат". Если Вам удобнее "результат LIMIT-а, кторый применён к rows, отсортированным в произвольном порядке" - я не против.

Ну не знаю, Ярослав. Для меня "unpredictable subset of the query's rows" - это "неопределённый результат". Если Вам удобнее "результат LIMIT-а, кторый применён к rows, отсортированным в произвольном порядке" - я не против.

Результат с нестрогими гарантиями

Ну не знаю, Ярослав. Для меня "unpredictable subset of the query's rows" - это "неопределённый результат". Если Вам удобнее "результат LIMIT-а, кторый применён к rows, отсортированным в произвольном порядке" - я не против.

А я знаю, Дмитрий. :) "unpredictable subset of the query's rows" переводится как "непредсказуемое подмножество rows [результата] запроса", кстати.

А я знаю, Дмитрий. :) "unpredictable subset of the query's rows" переводится как "непредсказуемое подмножество rows [результата] запроса", кстати.

Нет, ну это дословный перевод. А то что предлагаете Вы или Дарафей я классифицирую как "результат неопределён". Это могут быть последствия длительного влияния C++ ?

Если компаратор типа данных не говорит равно на неидентичные строки

Пусть у всех тип integer. Я делаю миллион инсертов (5, 5, 5).

Нет, ну это дословный перевод. А то что предлагаете Вы или Дарафей я классифицирую как "результат неопределён". Это могут быть последствия длительного влияния C++ ?

> Нет, ну это дословный перевод. Ну да, и это именно то, что гарантируется. > А то что предлагаете Вы или Дарафей я классифицирую как "результат неопределён". Не надо это так классифицировать. Здесь Вам не тут. ;) > Это могут быть последствия длительного влияния C++ ? Они и есть, похоже. Никакого undefined behavior (со всеми его ужасами) в SQL, к счастью, нет.

Пусть у всех тип integer. Я делаю миллион инсертов (5, 5, 5).

Ну вы б что-то интереснее взяли, хотя бы бинарный double и сигнальные NaN

Ну вы б что-то интереснее взяли, хотя бы бинарный double и сигнальные NaN

Я не прочь их взять после того, как мы с вами разберёмся с менее интересными для вас и интересными для меня типами - integer

> Нет, ну это дословный перевод. Ну да, и это именно то, что гарантируется. > А то что предлагаете Вы или Дарафей я классифицирую как "результат неопределён". Не надо это так классифицировать. Здесь Вам не тут. ;) > Это могут быть последствия длительного влияния C++ ? Они и есть, похоже. Никакого undefined behavior (со всеми его ужасами) в SQL, к счастью, нет.

Ну UB нет в SQL, конечно. Но ведь UB - это неопределённое поведение, а это совсем не то, что "неопределённый результат". Так что я всё же останусь при своей трактовке, с Вашего позволения ?

В общем, SQL не дает гарантий значительно сверх того, что написано его текстом при прочтении его как английского текста

В общем, SQL не дает гарантий значительно сверх того, что написано его текстом при прочтении его как английского текста

Мне нравится.

Ну UB нет в SQL, конечно. Но ведь UB - это неопределённое поведение, а это совсем не то, что "неопределённый результат". Так что я всё же останусь при своей трактовке, с Вашего позволения ?

А зря. Трактовка-то Ваша неправильная, и Вы просто [возможно] будете добавлять ORDER BY туда, где он совсем не нужен (и даже мешает).

А зря. Трактовка-то Ваша неправильная, и Вы просто [возможно] будете добавлять ORDER BY туда, где он совсем не нужен (и даже мешает).

Я добавляю ORDER BY везде, где присутсвует LIMIT. Ведь я не ищу приключений.

В общем, SQL не дает гарантий значительно сверх того, что написано его текстом при прочтении его как английского текста

Это ответ на мой вопрос с select ctid, a, b, c from test order by a, b, c offset 3 limit 2?

Я добавляю ORDER BY везде, где присутсвует LIMIT. Ведь я не ищу приключений.

А зачем?

Но, кстати, в SQL Implementation-dependent очень много (куда больше, чем в том же C, наверное), и запросы нужно писать так, чтобы результат от этого не зависел.

Это ответ на мой вопрос с select ctid, a, b, c from test order by a, b, c offset 3 limit 2?

Да. Вернется какая-то одинаковая сторка, непонятно, какая

Да. Вернется какая-то одинаковая сторка, непонятно, какая

Вообщем-то они все разные))

Так как у меня там ctid

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

ОМГ, окей

А зачем?

Потому что это соответствует рекомендациям документации — When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

Потому что это соответствует рекомендациям документации — When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

Ну а если мне всё равно? Или если я, к примеру, хочу unpredictable subset? ;)

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

Т.е. если я такой весь принципиальный и хочу их получить в определённом порядке, то мне нужно ещё sort по ctid делать? И там, видимо, компаратор должен правильно должен быть написан

Потому что это соответствует рекомендациям документации — When using LIMIT, it is a good idea to use an ORDER BY clause that constrains the result rows into a unique order. Otherwise you will get an unpredictable subset of the query's rows

Так ты об этом?))

Т.е. если я такой весь принципиальный и хочу их получить в определённом порядке, то мне нужно ещё sort по ctid делать? И там, видимо, компаратор должен правильно должен быть написан

У Вас просто должен быть PRIMARY KEY в каждой таблице, по-хорошему.

Окей

ctid между запросами тоже поехать может :)

В таблице с партициями он тоже повторится

?

Ну а если мне всё равно? Или если я, к примеру, хочу unpredictable subset? ;)

Тогда можно и без ORDER BY ?

например, без ордер бай удобно делать skip locked

Офигеть какой срач из-за одного запроса ))

да ваще

Тогда можно и без ORDER BY ?

А если для результата запроса это неважно, как в ранее приведённом примере? ;) Хотя, честно говоря: a) Этого почти никогда не бывает на практике. b) Даже в этом случае потеряна будет только производительность.

Офигеть какой срач из-за одного запроса ))

Наверное, потому, что ответ на него сразу показывает, понимает ли отвечающий важный принцип, лежащий в основе выполнения SQL-запросов — то, что почти всё может на самом деле выполняться в произвольном порядке (более того, планировщик имеет право выбирать этот порядок, игнорируя возможные runtime error). :)

А если для результата запроса это неважно, как в ранее приведённом примере? ;) Хотя, честно говоря: a) Этого почти никогда не бывает на практике. b) Даже в этом случае потеряна будет только производительность.

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

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

конечно, нет - ведь лишнее явное мешает строить оптимальный план запроса

конечно, нет - ведь лишнее явное мешает строить оптимальный план запроса

Это уже экспертный уровень.

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

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

конечно, нет - ведь лишнее явное мешает строить оптимальный план запроса

Не зря же тенденции таковы, что появляются такие языки, как Go. То, что в Си++, например, делается неявно, в Go намеренно предписано делать явным - проверять коды ошибок, тогда как в Си++ в любой момент может вылететь исключение. Потому что С++ расчитан на экспертов, Go - нет.

Всем привет. Не подскажите, если ли в posgre функция, которая вычисляет глубину дерева при Materialized Path?

Не зря же тенденции таковы, что появляются такие языки, как Go. То, что в Си++, например, делается неявно, в Go намеренно предписано делать явным - проверять коды ошибок, тогда как в Си++ в любой момент может вылететь исключение. Потому что С++ расчитан на экспертов, Go - нет.

Ну так и undefined behavior в C и C++, и unpredictable / implementation-dependent в SQL не просто так (и из SQL его и вовсе не уберут). ;)

Всем привет. Не подскажите, если ли в posgre функция, которая вычисляет глубину дерева при Materialized Path?

array_length(path, 1) ?

array_length(path, 1) ?

не, не так просто) интересует вычисление уровня вложенности, например рутовый элемент level 1, его дети level 2 и так далее.

не очень понятен вопрос. при Materialized Path же как раз то что я написал возвращает глубину конкретного элемента

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

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

не рутового, а произвольного

и?

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

ну то есть есть 1 | {1} 2 | {1,2} 3 | {1,2,3} 4 | {1,2,4} 5 | {1,2,5} 6 | {1,2,6} 7 | {1,2,3,7} и нужно посчитать глубину для 2 | {1,2} например? ну то есть что у него потомков максимум 2?

или вернуть все записи которые потомки этого элемента, но при этом показывать уровень аложенности?

чтобы в ответе было что-то вроде? 2 | {1,2} | 0 3 | {1,2,3} | 1 4 | {1,2,4} | 1 5 | {1,2,5} | 1 6 | {1,2,6} | 1 7 | {1,2,3,7} | 2

чтобы в ответе было что-то вроде? 2 | {1,2} | 0 3 | {1,2,3} | 1 4 | {1,2,4} | 1 5 | {1,2,5} | 1 6 | {1,2,6} | 1 7 | {1,2,3,7} | 2

да, наверное нужно написать функцию которая будет вырезать path корневого элемента из path элемента, а далее array_length

да просто array_length(path - root_path, 1)

@ded_d555 будет жить. Поприветствуем!

да просто array_length(path - root_path, 1)

даже так) спасибо

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

Доброго времени суток. Подскажите есть ли способ сбэкапить базу данных postgresql через pg_dump на сетевой источник типа: NFS FTP (over curlftpfs) Проблема: ошибка ввода вывода т.к. сторонний ресурс не подконтрольный мне (не я разворачивал сервак с хранилищем, а оно от хостера как сервис). Следовательно мотируется как root или еще какой другой пользователь. Когда резервировался на свою самбу, то разруливал это через опции монтирования. Монтировал как от пользователя postgres.

Доброго времени суток. Подскажите есть ли способ сбэкапить базу данных postgresql через pg_dump на сетевой источник типа: NFS FTP (over curlftpfs) Проблема: ошибка ввода вывода т.к. сторонний ресурс не подконтрольный мне (не я разворачивал сервак с хранилищем, а оно от хостера как сервис). Следовательно мотируется как root или еще какой другой пользователь. Когда резервировался на свою самбу, то разруливал это через опции монтирования. Монтировал как от пользователя postgres.

> Подскажите есть ли способ сбэкапить базу данных postgresql через pg_dump Ну, для начала, dump — не backup. ;) Если Вам нужен backup, используйте pg_basebackup. > Следовательно мотируется как root или еще какой другой пользователь. А что, если запускать backup из-под этого пользователя? Или же делать локально, потом копировать?

> Подскажите есть ли способ сбэкапить базу данных postgresql через pg_dump Ну, для начала, dump — не backup. ;) Если Вам нужен backup, используйте pg_basebackup. > Следовательно мотируется как root или еще какой другой пользователь. А что, если запускать backup из-под этого пользователя? Или же делать локально, потом копировать?

Локально это неприемлемо т.к. локальных ресурсов для этого не хватает. pg_dump - средство создания логического бэкапа конкретной БД.

Локально это неприемлемо т.к. локальных ресурсов для этого не хватает. pg_dump - средство создания логического бэкапа конкретной БД.

Дампа, а не backup-а. Совсем разные вещи. Ну ладно, а какой у Вас есть доступ к этим ресурсам? Кстати, pg_basebackup / pg_dump можно было бы запускать и "с той стороны"... но это Вам не подойдёт, как я понимаю? И ещё, вообще-то пользователи PostgreSQL и OS никак не связаны (кроме возможности некоторых видов аутентификации).

Шара SaaS. Оттуда никак.

Шара SaaS. Оттуда никак.

Ну так Вы вообще можете хоть под каким-то пользователем туда скопировать? Если да, см. "пользователи PostgreSQL и OS никак не связаны", т.е. делайте dump из-под этого пользователя OS.

Дампа, а не backup-а. Совсем разные вещи. Ну ладно, а какой у Вас есть доступ к этим ресурсам? Кстати, pg_basebackup / pg_dump можно было бы запускать и "с той стороны"... но это Вам не подойдёт, как я понимаю? И ещё, вообще-то пользователи PostgreSQL и OS никак не связаны (кроме возможности некоторых видов аутентификации).

Я прошу прощения, конечно, но pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently.

Я прошу прощения, конечно, но pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently.

Да, я знаю, что там это написано, и что? Вы вот, например, DBA? ;)

Pg_basebackup, кто знает как оно внутри работает? Или что можно ответить людям, когда спрашивают как оно работает внутри?

Да, я знаю, что там это написано, и что? Вы вот, например, DBA? ;)

Ну, как минимум то, что то, что написано в официальной документации, то и является объективной реальностью ? Если написано, что pg_dump - это средство для создания резервных копий, значит так оно и есть. А что, надо читать одно, а подразумевать другое? Я не знаю кто владеет этим тайным искусством ?

Pg_basebackup, кто знает как оно внутри работает? Или что можно ответить людям, когда спрашивают как оно работает внутри?

"Файловый", бинарный backup снимает, грубо говоря (+ WAL). А в документации это не описано (я не помню)?

Ну, как минимум то, что то, что написано в официальной документации, то и является объективной реальностью ? Если написано, что pg_dump - это средство для создания резервных копий, значит так оно и есть. А что, надо читать одно, а подразумевать другое? Я не знаю кто владеет этим тайным искусством ?

> Ну, как минимум то, что то, что написано в официальной документации, то и является объективной реальностью Ничего подобного. Там вообще немало, ээ... "интересного" написано. :) В данном случае, написанное — личное мнение кого-то из разработчиков PostgreSQL (и даже не одного). Но вряд ли они сами DBA, и разбираются в этом. ;) Хотя, может быть, это и вопрос терминологии. DBA обычно считают backup средства, подходящие для disaster recovery.

"Файловый", бинарный backup снимает, грубо говоря (+ WAL). А в документации это не описано (я не помню)?

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

А Вы, Ярослав, смелый очень, надо сказать ?

А Вы, Ярослав, смелый очень, надо сказать ?

А чего бояться-то? ;) Правду говорить легко и приятно. :) Вот, например, прямо в приведённой фразе: > It makes consistent backups even if the database is being used concurrently. Строго говоря, неправда (т.е. конкуретный DDL может дать Вам "сломанный" dump, если сильно не повезёт). :(

А чего бояться-то? ;) Правду говорить легко и приятно. :) Вот, например, прямо в приведённой фразе: > It makes consistent backups even if the database is being used concurrently. Строго говоря, неправда (т.е. конкуретный DDL может дать Вам "сломанный" dump, если сильно не повезёт). :(

Не согласен с тем что легко. Иногда хочется оправдать ожидания начальства, но понимаешь что сделать при нынешних средствах это сейчас невозможно.

И далеко не всегда приятно. Но то что говорить что разрабы Постгре - такие же смертные люди даже нужно. Иначе начинается молитва на доку и вера во все что они скажут прямо как с британскими учеными

Ну да. Все мы люди, все ошибаемся. Да и вообще, как говорится, для разработчиков СУБД её пользователи — просто тестовая нагрузка. ;) Я тому, что сами они, в основном не DBA, а разработчики; и многие из них заняты в основном разработкой PostgreSQL, а не применением его в своих проектах, поэтому у них угол зрения не такой, как, например, у нас. ;)

Ну да. Все мы люди, все ошибаемся. Да и вообще, как говорится, для разработчиков СУБД её пользователи — просто тестовая нагрузка. ;) Я тому, что сами они, в основном не DBA, а разработчики; и многие из них заняты в основном разработкой PostgreSQL, а не применением его в своих проектах, поэтому у них угол зрения не такой, как, например, у нас. ;)

Ну так то Вы правы, что все ошибаются. Но вот ставить под сомнение терминологию и документацию утилит Постгреса, которым уже добрых 2 десятка лет (больше), я бы столь откровенно не решился ? А что Вы считаете резервной копией БД в таком случае? Актуализированную реплику что-ли?

> Но вот ставить под сомнение терминологию и документацию утилит Постгреса, которым уже добрых 2 десятка лет (больше), А я слышал, некоторые другие СУБД (которым уже больше 3 десятков лет), вообще бессовестно лгут в своей документации, и ничего. :) > я бы столь откровенно не решился ? Ну ошиблись люди, это не их "огород", и что тут такого? > А что Вы считаете резервной копией БД в таком случае? Хотя бы pg_basebackup. Потому что на его основании можно добиться целевых RTO/RPO, а pg_dump для этого как-то не очень (скорее очень не) подходит. > Актуализированную реплику что-ли? Да, тоже может быть частью стратегии disaster recovery. От требований зависит.

Orifjon будет жить. Поприветствуем!

Добрый вечер. У меня вопрос, есть таблица в Ms Excel (расписание уроков для колледжа) хочу чтоб Телеграмм бот с базы MS Excel по группам или по дням брал столбцы и показывал расписание уроков. Как это реализовать?

Типа "Расписание - Финунивер" но я не разбираюсь в програмирование Phiton, разработчик мне по советовал типа PostgreS чтоб проста с Ms Excel экспортировал таблицу по запросу.

Как это реализовать в какой канал? Куда?

Как это реализовать в какой канал? Куда?

А кто его знает... Но, казалось бы, зачем здесь PostgreSQL (сам по себе он из Excel данные получать не умеет, насколько я знаю... хотя, может и есть какой-нибудь FDW в интернете)? Но даже если Вы эти данные в таблицу PostgreSQL импортируете, чем это легче? Всё равно же их надо будет как-то этим ботом вытаскивать... Поищите канал(ы) про программирование telegram-ботов, наверное.

ок. Спасибо

А кто его знает... Но, казалось бы, зачем здесь PostgreSQL (сам по себе он из Excel данные получать не умеет, насколько я знаю... хотя, может и есть какой-нибудь FDW в интернете)? Но даже если Вы эти данные в таблицу PostgreSQL импортируете, чем это легче? Всё равно же их надо будет как-то этим ботом вытаскивать... Поищите канал(ы) про программирование telegram-ботов, наверное.

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