Со всем уважением, Вы понятия не имеете, о чём говорите. :(

Чего?

Вот Линус Торвальдс - это основной разработчик Линукса. Он его основал.

Основной был Стоунбрейкер.

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

А Постгрес основал Стоунбрейкер, а не Том Лэйн.

Учите историю.

Вот Линус Торвальдс - это основной разработчик Линукса. Он его основал.

Не имеет значения, кто что основал. Важно, что есть здесь и сейчас.

Имеет. Основной от слова "основа".

Сюрприз?

Сколько потуг на ровном месте ))

Учите историю.

Зачем? Вы сами-то пробовали этот ужас читать? Хорошо, что хоть кое-что, "основанное" Стоунбрейкером, из проекта выкинули. :) > Имеет. Основной от слова "основа". Мне за словарём сходить? Или мы тут демагогией будем заниматься?

Спасибо. Вот так бы сразу.

Скоро придётся напомнить в чем суть спора:) Гнев затмевает разум

Зачем? Вы сами-то пробовали этот ужас читать? Хорошо, что хоть кое-что, "основанное" Стоунбрейкером, из проекта выкинули. :) > Имеет. Основной от слова "основа". Мне за словарём сходить? Или мы тут демагогией будем заниматься?

Идите куда хотите ) Не мне Вам указывать направление )

Идите куда хотите ) Не мне Вам указывать направление )

> Гнев затмевает разум > Сколько потуг на ровном месте )) Кстати, да. :(

Скоро придётся напомнить в чем суть спора:) Гнев затмевает разум

Суть спора в том, что нет ничего плохого в использовании "опасных" инструментов. Проблема не в них, а в тех, кто ими пользоваться не умеет. Причём тут разного рода авторитеты с их блогами - совершенно непонятно. Зачем навязывать чьё-то мнение?

Когда дискуссия сказывается к взыванию к авторитетам, а не к реальным аргументам, то дальше смысла обсуждать что-либо нет. Ну вот Линусу Торвальдсу не нравится C++. Это значит, что на нём не надо писать программы? Для кого-то - да. Этот кто-то во всех разговорах будет ссылаться на высказывания своего кумира. Остальных это не волнует. C++ - прекрасный язык.

Суть спора в том, что нет ничего плохого в использовании "опасных" инструментов. Проблема не в них, а в тех, кто ими пользоваться не умеет. Причём тут разного рода авторитеты с их блогами - совершенно непонятно. Зачем навязывать чьё-то мнение?

Нет, суть спора не в этом. А в том, что это не "опасный инструмент", это такая штука, которую невоможно ипользовать правильно (как утверждают разработчики PostgreSQL, в разных местах)!

Нет, суть спора не в этом. А в том, что это не "опасный инструмент", это такая штука, которую невоможно ипользовать правильно (как утверждают разработчики PostgreSQL, в разных местах)!

Ну так напишите в @hackers предолжение убрать эту "бессмысленную" фичу. Толку будет больше.

да с ним бесполезно спорить, он вон на запрос к конкретному набору данных, который гарантированно вернет только 1 запись из-за группировки и лимита поставит сортировку, чтобы не было непредсказуемого результата, а результат без сортировки будет считать неопределенным

Когда дискуссия сказывается к взыванию к авторитетам, а не к реальным аргументам, то дальше смысла обсуждать что-либо нет. Ну вот Линусу Торвальдсу не нравится C++. Это значит, что на нём не надо писать программы? Для кого-то - да. Этот кто-то во всех разговорах будет ссылаться на высказывания своего кумира. Остальных это не волнует. C++ - прекрасный язык.

Ну так покажите нам полезное и корректное, нетривиальное RULE. А потом (статья-то не зря называется "The Rule Challenge") — покажите его RhodiumToad (хоть сейчас), и он Вам продемонстрирует, как "лёгким движением руки" Ваши данные при его использовании превратятся в тыкву. :(

Ну так напишите в @hackers предолжение убрать эту "бессмысленную" фичу. Толку будет больше.

Толку не будет. Вы, похоже, невнимательно читаете. Я уже объяснял, почему.

Ну так покажите нам полезное и корректное, нетривиальное RULE. А потом (статья-то не зря называется "The Rule Challenge") — покажите его RhodiumToad (хоть сейчас), и он Вам продемонстрирует, как "лёгким движением руки" Ваши данные при его использовании превратятся в тыкву. :(

Ну так можно и лоб себе расшибить, если сильно наклониться. Кого это интересует?

Ну раз фича до сих пор в Постгресе, значит её можно использовать. Пользуйтесь на здоровье.

да с ним бесполезно спорить, он вон на запрос к конкретному набору данных, который гарантированно вернет только 1 запись из-за группировки и лимита поставит сортировку, чтобы не было непредсказуемого результата, а результат без сортировки будет считать неопределенным

Да. Ну и что?

Вы пол дня потратили на фигню

Вы пол дня потратили на фигню

А Вы на что потратили?

Да. Ну и что?

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

Ну раз фича до сих пор в Постгресе, значит её можно использовать. Пользуйтесь на здоровье.

Ну так поиспользуйте, например, "TIME WITH TIMEZONE". Все Ваши аргументы подходят, но тем не менее, это бесполезная ерунда, и каждое его использование — ошибка. (А почему он есть в PostgreSQL, я уже объяснял.)

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

Не вижу смысла думать о том, что уже придумано и чётко изложено.

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

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

Нет, я не понял что он прав.

Никакого принципа тут нет.

И снова вы обратили внимание только на спор

А, продолжение хабра. Так можно же попробовать. ;)

И снова вы обратили внимание только на спор

А на что надо обратить внимание? Примеры использования правил чётко изложены в официальной документации. Не в вики, не в блоге, а в документации.

Ну так покажите нам полезное и корректное, нетривиальное RULE. А потом (статья-то не зря называется "The Rule Challenge") — покажите его RhodiumToad (хоть сейчас), и он Вам продемонстрирует, как "лёгким движением руки" Ваши данные при его использовании превратятся в тыкву. :(

?

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

?

В документации.

А на что надо обратить внимание? Примеры использования правил чётко изложены в официальной документации. Не в вики, не в блоге, а в документации.

И совет их не использовать тоже изложен в документации. :)

В документации.

Кстати да, можно будет его спросить. А то примеров в статье как-то... нет. ;)

А?

И совет их не использовать тоже изложен в документации. :)

Где это?

Где это?

https://www.postgresql.org/docs/current/static/rules-update.html In many cases, tasks that could be performed by rules on INSERT/UPDATE/DELETE are better done with triggers. Triggers are notationally a bit more complicated, but their semantics are much simpler to understand. Rules tend to have surprising results when the original query contains volatile functions: volatile functions may get executed more times than expected in the process of carrying out the rules. Also, there are some cases that are not supported by these types of rules at all, notably including WITH clauses in the original query and multiple-assignment sub-SELECTs in the SET list of UPDATE queries. This is because copying these constructs into a rule query would result in multiple evaluations of the sub-query, contrary to the express intent of the query's author.

https://www.postgresql.org/docs/current/static/rules-update.html In many cases, tasks that could be performed by rules on INSERT/UPDATE/DELETE are better done with triggers. Triggers are notationally a bit more complicated, but their semantics are much simpler to understand. Rules tend to have surprising results when the original query contains volatile functions: volatile functions may get executed more times than expected in the process of carrying out the rules. Also, there are some cases that are not supported by these types of rules at all, notably including WITH clauses in the original query and multiple-assignment sub-SELECTs in the SET list of UPDATE queries. This is because copying these constructs into a rule query would result in multiple evaluations of the sub-query, contrary to the express intent of the query's author.

Ах это. Ну так я в самом начале говорил, что согласен с тем, что во многих случаях триггеры проще.

Но это совсем не значит, что от правил надо шарахаться.

misteri di cdcqq: come faccio ad avere più di 17 views per entry

Привет всем кто не спит) Начал экспоненциально расти pg_xlog, за час скушал 70ГБ (всё место)

может кто натолкнуть на мысль, чем это могло быть вызвано?

может кто натолкнуть на мысль, чем это могло быть вызвано?

Replication slot, проблема с archive_command, hot_standby_feedback... ну, prepared transaction, в приниципе.

Или просто идёт огромная транзакция, да и всё...

Replication slot, проблема с archive_command, hot_standby_feedback... ну, prepared transaction, в приниципе.

спасибо, слотов репликаций нет, остальное буду смотреть

?

А?

Про пример "весёлого" поведения с тем, что есть в документации (мне подсказали): shoelace_data: sl_name | sl_avail | ---------+----------+----------+ a_name | 6 | -- В сессии номер 1: BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED; UPDATE shoelace_data SET sl_avail = 8 WHERE sl_name = 'a_name'; -- В сессии номер 2: BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED; UPDATE shoelace_data SET sl_avail = 6 WHERE sl_name = 'a_name'; -- блокируется -- В сессии номер 1: COMMIT; -- В сессии номер 2: COMMIT; ​И в результате, в shoelace_data: sl_name | sl_avail | ---------+----------+ a_name | 6 | А вот в логе: sl_name | sl_avail | log_who | log_when ---------+----------+----------+-------------------- a_name | 8 | postgres | 2018-09-20 23:41:46 Мне одному кажется, что здесь чего-то не хватает? ;)

Про пример "весёлого" поведения с тем, что есть в документации (мне подсказали): shoelace_data: sl_name | sl_avail | ---------+----------+----------+ a_name | 6 | -- В сессии номер 1: BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED; UPDATE shoelace_data SET sl_avail = 8 WHERE sl_name = 'a_name'; -- В сессии номер 2: BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED; UPDATE shoelace_data SET sl_avail = 6 WHERE sl_name = 'a_name'; -- блокируется -- В сессии номер 1: COMMIT; -- В сессии номер 2: COMMIT; ​И в результате, в shoelace_data: sl_name | sl_avail | ---------+----------+ a_name | 6 | А вот в логе: sl_name | sl_avail | log_who | log_when ---------+----------+----------+-------------------- a_name | 8 | postgres | 2018-09-20 23:41:46 Мне одному кажется, что здесь чего-то не хватает? ;)

Ну и что это доказывает? Это доказывает лишь неприемлемость данного решения в конкурентной среде.

Используйте AFTER-триггеры для протоколирования, что тут сказать ещё?

Ну и что это доказывает? Это доказывает лишь неприемлемость данного решения в конкурентной среде.

Это доказывает, что даже в примерах из документации есть то, о чём она же и предупреждает (неожиданные неприятные "сюрпризы"). А с триггером (которые там и советуют) сработало бы, да... Т.е. это RULE — неправильное. Так как это вроде бы единственное DO ALSO RULE, которое есть в документации... Может быть, есть другие примеры? Или всё же, как утверждают все, кого я цитировал, с RULE "каши не сваришь"?

Причём такие примеры, кстати, чтобы использование RULE было оправдано, т.е. оно было явно лучше триггеров (которые являются куда более прозрачным механизмом и т.п.).

Посмотрю потом в прошлых разработках есть ли что-нибудь в качестве примера.

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

Так как немного читал про локи недавно, рискну предположить что 15 и 120? Рассуждаю так: первая лочит все строки, вторая находит строку где была 15 и ждёт лок на нее, первая комиттит строки 15 и 20 и освобождает лок, вторая получив Лок на ту строку где была 15, а сейчас 20 вычисляет значение для записи используя новое значение в строки (ибо read committed) -120

Так как немного читал про локи недавно, рискну предположить что 15 и 120? Рассуждаю так: первая лочит все строки, вторая находит строку где была 15 и ждёт лок на нее, первая комиттит строки 15 и 20 и освобождает лок, вторая получив Лок на ту строку где была 15, а сейчас 20 вычисляет значение для записи используя новое значение в строки (ибо read committed) -120

Логично, но нет)

А какой результат (без объяснения)? На телефоне, проверить не могу :)

15 115?

15 115?

Не-а :)

Хммм если лок только на запись, а вычисление значения идёт вовремя чтения (что наверное логично), то должно быть 15 и 115 :)

Рул дипрейкатит тем неменее. Его можно использовать как хак на свой страх и риск. Как временное решение чтобы что-то куда то перенаправить. Пример с хабра это пример из документации — читайте блин документацию люди

https://www.postgresql.org/docs/10/static/transaction-iso.html#XACT-READ-COMMITTED

Пример про website

Ключ: The search condition of the command (the WHERE clause) is re-evaluated to see if the updated version of the row still matches. Вторая транзакция просто не обновит ничего, т.к. пропустит первую строку потому что where не сработает вовремя чтения (там 10) и пропустит вторую строку, т.к. после взятия лока перепроверит where и оно снова не сработает (там уже 20). Итого в таблице останется 15 и 20

Ключ: The search condition of the command (the WHERE clause) is re-evaluated to see if the updated version of the row still matches. Вторая транзакция просто не обновит ничего, т.к. пропустит первую строку потому что where не сработает вовремя чтения (там 10) и пропустит вторую строку, т.к. после взятия лока перепроверит where и оно снова не сработает (там уже 20). Итого в таблице останется 15 и 20

?это уже не пальцем в небо)

Это не read committed, йо!

А будет 20 и 115

А будет 20 и 115

Почему?

Всем добра! Подскажите, можно ли как нибудь на уровне сессии понизить привилегии до read-only?

Почему?

По логике работы тех транзакций

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

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

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

Здравствуйте, коллеги. Я специалист по Oracle, в PostgreSQL новенький, возник вопрос при миграции процедуры (функции): Есть функция с обычними параметрами и out refcursor. Как тут использовать FETCH ALL чтобы возвращал записи?

Всем добра! Подскажите, можно ли как нибудь на уровне сессии понизить привилегии до read-only?

Суперпользователь может - https://www.postgresql.org/docs/10/static/sql-set-session-authorization.html

Здравствуйте, коллеги. Я специалист по Oracle, в PostgreSQL новенький, возник вопрос при миграции процедуры (функции): Есть функция с обычними параметрами и out refcursor. Как тут использовать FETCH ALL чтобы возвращал записи?

Т.е. функция должа возвращать таблицу?

Т.е. функция должа возвращать таблицу?

Да. 2 курсора, 1 количество возврщает другой таблицу

Я вижу у Вас 1 out-параметр, который курсор. Вы ещё хотите, чтобы функция вернула ещё один курсор или набор строк? Не совсем понятно.

Вот посмотрите

Суперпользователь может - https://www.postgresql.org/docs/10/static/sql-set-session-authorization.html

спасибо, но мне, к сожалению, не подойдет.

спасибо, но мне, к сожалению, не подойдет.

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