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

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

Конечно, нет — либо триггеры, либо вручную. (Да, если кто-то вспомнит про RULES — их очень не советуют, и не без причины.) Кстати, а как это у Вас так получается, что в любой вставке в табл1 есть вся информация для новой записи в табл2? ;)

Я вспомню RULES - мощнейшее средство в PostgreSQL.

Я вспомню RULES - мощнейшее средство в PostgreSQL.

А зря, зря. Можно так "напороть", что мало не покажется, причём запросто. :(

А зря, зря. Можно так "напороть", что мало не покажется, причём запросто. :(

Ну так везде можно "напороть", даже когда чайник кипятишь. Что же теперь, чай не пить? ?

Ну так везде можно "напороть", даже когда чайник кипятишь. Что же теперь, чай не пить? ?

Это уж скорее из серии: "что же теперь, взрывчатку дома не использовать?!" ;) http://blog.rhodiumtoad.org.uk/2010/06/21/the-rule-challenge/

Так вот для той цели, про которую спрашивали, видимо, требуется DO ALSO. И вот: All non-trivial rules are incorrect. I define “non-trivial” as follows: <skip> . Any rule using DO ALSO is non-trivial.

А зря, зря. Можно так "напороть", что мало не покажется, причём запросто. :(

например?

например?

Я ссылку уже дал, см. выше.

Это уж скорее из серии: "что же теперь, взрывчатку дома не использовать?!" ;) http://blog.rhodiumtoad.org.uk/2010/06/21/the-rule-challenge/

Это всё понятно. Но в ряде случаев, правила оказываются гораздо эффективнее. Поэтому их используют без оглядки на возможные проблемы. Прямо как C используют для написания тех же расширений без оглядки на возможное падение сервера в случае ошибки, когда речь заходит про эффективность. Кому нужен безопасный питончик, если его использование в конкретной задаче снизит производительность на 3 порядка против C или C++? Никому. Разве что таким же медленным по жизни (есть одно подходящее слово в этом случае) ?

> Но в ряде случаев, правила оказываются гораздо эффективнее. Эффективность "решения", которое на самом деле не решает задачу, равна нулю. ;) > Кому нужен безопасный питончик, если его использование в конкретной задаче снизит производительность на 3 порядка против C или C++? Никому. Ну-ну. Что ж мы все в машинном коде-то не пишем? ;) (А дело-то всё во времени (деньгах), разве нет?) > Разве что таким же медленным по жизни (есть одно подходящее слово в этом случае) ? И это слово "профессионалы"? ;) ;) Интересный у Вас взгляд, вообще говоря... Базы данных гораздо "дороже" (в плане производительности) других подходов, которые вроде как решают ту же задачу (ну, в 99.99% случаев). И, тем не менее, многие пользуются...

> Но в ряде случаев, правила оказываются гораздо эффективнее. Эффективность "решения", которое на самом деле не решает задачу, равна нулю. ;) > Кому нужен безопасный питончик, если его использование в конкретной задаче снизит производительность на 3 порядка против C или C++? Никому. Ну-ну. Что ж мы все в машинном коде-то не пишем? ;) (А дело-то всё во времени (деньгах), разве нет?) > Разве что таким же медленным по жизни (есть одно подходящее слово в этом случае) ? И это слово "профессионалы"? ;) ;) Интересный у Вас взгляд, вообще говоря... Базы данных гораздо "дороже" (в плане производительности) других подходов, которые вроде как решают ту же задачу (ну, в 99.99% случаев). И, тем не менее, многие пользуются...

В машинном коде не пишут, потому что это: a) неоправданно сложно; b) абсолютно непереносимо. Дело в деньгах и времени, да. Поэтому создали давно уже кросс-платформенный ассемблер, назвали его C. Компиляторы C научились генерить крайне эффективный машкод. Поэтому смысла писать в машкоде сейчас уже нет. Зато есть смысл писать на C или C++, когда речь заходит про эффективность. Да, это сложные инструменты. Но никто от них отказываться не будет, потому что по эффективности и возможностям ничего другого на горизонте не видно. Так же и с правилами из PostgreSQL. Кому нужна мощная и точная "пушка", тому чихать на какие-то там потенциальные проблемы. Речь об эффективности, т.е. о времени, т.е. о деньгах. С денег начали, ими и закончим. ?

А вроде бы и не пятница...

Ага, а уже понеслось

> Поэтому создали давно уже кросс-платформенный ассемблер, назвали его C. Компиляторы C научились генерить крайне эффективный машкод. Поэтому смысла писать в машкоде сейчас уже нет. Отчасти это верно. На уровне "отдельных элементов" код довольно эффективен. Тем не менее, есть приёмы, на которые "кросс-платформенный ассемблер" просто неспособен (самомодифицирующийся код, например, или хранение доп. информации в указателях (есть случаи, когда это безопасно, да)). К счастью, алгоритмов, эффективность которых зависит от этих приёмов, немного, к тому же, кое-что решает JIT. > Но никто от них отказываться не будет, потому что по эффективности и возможностям ничего другого на горизонте не видно. Никто — это сильное преувеличение. Опять-таки, зависит от того, что выгодно (чаще всего можно просто решить "железом"). Какие у них там уникальные возможности, кстати? > Так же и с правилами из PostgreSQL. Кому нужна мощная и точная "пушка", тому чихать на какие-то там потенциальные проблемы. Не вижу логики... Как Вы это вычисляете? Допустим, в какой то ситуации rules чуть производительнее триггеров, так что можно взять "железо" на 1000$ дешевле... а цена любой ошибки, к примеру, 10000$. Всё ещё стоит использовать? > С денег начали, ими и закончим. Непохоже как-то. :(

> Поэтому создали давно уже кросс-платформенный ассемблер, назвали его C. Компиляторы C научились генерить крайне эффективный машкод. Поэтому смысла писать в машкоде сейчас уже нет. Отчасти это верно. На уровне "отдельных элементов" код довольно эффективен. Тем не менее, есть приёмы, на которые "кросс-платформенный ассемблер" просто неспособен (самомодифицирующийся код, например, или хранение доп. информации в указателях (есть случаи, когда это безопасно, да)). К счастью, алгоритмов, эффективность которых зависит от этих приёмов, немного, к тому же, кое-что решает JIT. > Но никто от них отказываться не будет, потому что по эффективности и возможностям ничего другого на горизонте не видно. Никто — это сильное преувеличение. Опять-таки, зависит от того, что выгодно (чаще всего можно просто решить "железом"). Какие у них там уникальные возможности, кстати? > Так же и с правилами из PostgreSQL. Кому нужна мощная и точная "пушка", тому чихать на какие-то там потенциальные проблемы. Не вижу логики... Как Вы это вычисляете? Допустим, в какой то ситуации rules чуть производительнее триггеров, так что можно взять "железо" на 1000$ дешевле... а цена любой ошибки, к примеру, 10000$. Всё ещё стоит использовать? > С денег начали, ими и закончим. Непохоже как-то. :(

Самомодифицирующийся код - это красивая легенда, от которой отказались даже в PostgreSQL. Изначально эта СУБД была написана на Lisp, в котором уж "самомодифицирующийся код" во все поля. Потом перешли на "кросс-платформенный ассемблер" и вздохнули с облегчением, потому как только на C удалось работать на низком уровне. Все расширения, требующие производительности (а это все официльные расширения и большинство неофициальных расширений) пишутся на C. Прекрасно обходятся без самомодифицирующихся возможностей. (От которых всё равно одни тормоза.) А как Вы вычисляете цену ошибки? Что это у Вас вдруг за величины $1000 vs $10000?

> Самомодифицирующийся код - это красивая легенда, от которой отказались даже в PostgreSQL. Какая ещё легенда!? ;) Есть алгоритмы, эффективная реализация которых без него невозможна (и их есть даже в TAOCP, не говоря уже о прочих областях). > Прекрасно обходятся без самомодифицирующихся возможностей. (От которых всё равно одни тормоза.) А JIT в v11 зачем добавляют, в таком случае? ;) > А как Вы вычисляете цену ошибки? Что это у Вас вдруг за величины $1000 vs $10000? Как-то вычисляю. :) Это же был пример... Стоимость "железа" вычислить более-менее несложно, а вот с ценой ошибки да, бывает по-разному (можно и "на все деньги" влететь, а может и повезти). Просто дело в том, что когда в одном месте (организации, продукте) начинают накапливаться "решения", работающие в 99.99% случаев... всё зачастую (и довольно быстро) становится грустно.

> Самомодифицирующийся код - это красивая легенда, от которой отказались даже в PostgreSQL. Какая ещё легенда!? ;) Есть алгоритмы, эффективная реализация которых без него невозможна (и их есть даже в TAOCP, не говоря уже о прочих областях). > Прекрасно обходятся без самомодифицирующихся возможностей. (От которых всё равно одни тормоза.) А JIT в v11 зачем добавляют, в таком случае? ;) > А как Вы вычисляете цену ошибки? Что это у Вас вдруг за величины $1000 vs $10000? Как-то вычисляю. :) Это же был пример... Стоимость "железа" вычислить более-менее несложно, а вот с ценой ошибки да, бывает по-разному (можно и "на все деньги" влететь, а может и повезти). Просто дело в том, что когда в одном месте (организации, продукте) начинают накапливаться "решения", работающие в 99.99% случаев... всё зачастую (и довольно быстро) становится грустно.

JIT в C# есть, в Java, даже в JS. Означает ли это что они самомодифицируются на лету? Нет (хотя возможности есть в каждом из перечисленных языков, но к JIT'у это относится примерно никак).

JIT в C# есть, в Java, даже в JS. Означает ли это что они самомодифицируются на лету? Нет (хотя возможности есть в каждом из перечисленных языков, но к JIT'у это относится примерно никак).

> Означает ли это что они самомодифицируются на лету? Кто "они"? > но к JIT'у это относится примерно никак Почему, конкретно? IMHO, у самомодифицирующегося кода и JIT есть кое-что общее.

> Означает ли это что они самомодифицируются на лету? Кто "они"? > но к JIT'у это относится примерно никак Почему, конкретно? IMHO, у самомодифицирующегося кода и JIT есть кое-что общее.

"Они" - программы, написанные на этих языках. JIT позволяет нам на лету скомпилить из условного байт-кода машинный, с учётом особенностей того железа, на котором мы работаем. Если JIT умный, то он ещё и в рантайме статистику пособирает и дополнительно оптимизирует наиболее горячие участки кода (Tiered JIT). Но это скорее про портируемость кода, чем про самомодифицирующийся код.

Но да, можно написать само-модифицирующийся код через генерацию байт-кода в рантайме/eval в js

> Но это скорее про портируемость кода, чем про самомодифицирующийся код. Ну это уже вопрос терминологии, IMHO... Чем кардинально самомодифицирующийся код от этого отличается? Только совпадением "языка", его генерирующего (или модифицирующего), с генерируемым (т.е. это машинный код)?

Если уж тут пошла речь про самомодифицирующийся код, то как раз таки rules в PostgreSQL - это яркий пример этого.

Как раз именно этим система правил и занимается - переписывает запросы в соответствии с правилами.

у меня есть две таблицы Students и Groups возможно ли накинуть индекс на колонку students.id и groups.subject_id ? или впринципе такого нельзя сделать?

Как раз именно этим система правил и занимается - переписывает запросы в соответствии с правилами.

Да. И делает это (в указанных случаях) плохо. Т.е. broken by design. :(

у меня есть две таблицы Students и Groups возможно ли накинуть индекс на колонку students.id и groups.subject_id ? или впринципе такого нельзя сделать?

Один индекс на две таблицы, в смысле? Если да — нет, нельзя.

спасибо

Да. И делает это (в указанных случаях) плохо. Т.е. broken by design. :(

Нет ничего идеального. Чем мощнее средство, чем ближе оно к практике, тем больше у него недостатков.

Нет ничего идеального. Чем мощнее средство, чем ближе оно к практике, тем больше у него недостатков.

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

Суть-то в том, что RULE здесь невозможно написать так, чтобы оно работало во всех ситуациях (в отличие от триггера)!

Я не возражаю. Конечно надо смотреть по ситуации. Просто мне показалось, что Вы категорический противник использания правил в принципе.

Правила - это мощное средство. Не стоит их боятся. Ими стоит уметь пользоваться.

Я не возражаю. Конечно надо смотреть по ситуации. Просто мне показалось, что Вы категорический противник использания правил в принципе.

Да, так и есть (в смысле, да, противник).

Правила - это мощное средство. Не стоит их боятся. Ими стоит уметь пользоваться.

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

Я не в курсе, Ярослав, что ими нельзя пользоваться. Лично пользуюсь и очень доволен. Видимо, другие пользователи (кто умеет пользоваться, конечно) тоже довольны, раз система правил в Постгресе почти с самого начала и по сей день.

Я не в курсе, Ярослав, что ими нельзя пользоваться. Лично пользуюсь и очень доволен. Видимо, другие пользователи (кто умеет пользоваться, конечно) тоже довольны, раз система правил в Постгресе почти с самого начала и по сей день.

Нет, им кажется, что они умеют. :( Вы статью читали? Знаете, кто автор? А комментаторы? Вот Вам более-менее официальная позиция проекта по этому поводу: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules

Резюме оттуда: > When should you? Never. While the rewriter is an implementation detail of VIEWs, there is no reason to pry up this cover plate directly.

я туплю или рулы используются в 9.х для партиционирования?

я туплю или рулы используются в 9.х для партиционирования?

Обычно используются триггеры.

Нет, им кажется, что они умеют. :( Вы статью читали? Знаете, кто автор? А комментаторы? Вот Вам более-менее официальная позиция проекта по этому поводу: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules

Это из той же оперы, где поют "никогда не используйте C". Но кого волнуют эти песни?

Если почти всё чуть более дельное пишется на C или C++ по сей день. Включая Постгрес.

Это из той же оперы, где поют "никогда не используйте C". Но кого волнуют эти песни?

То есть, прямые предупреждения основных разработчиков (да, кстати, они есть и в документации), Вас не впечатляют? ;) Ну удачи, что тут скажешь. :(

Если почти всё чуть более дельное пишется на C или C++ по сей день. Включая Постгрес.

сейчас бы JIT копилятор переписать на java, а не вот это вот все...

Если почти всё чуть более дельное пишется на C или C++ по сей день. Включая Постгрес.

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

То есть, прямые предупреждения основных разработчиков (да, кстати, они есть и в документации), Вас не впечатляют? ;) Ну удачи, что тут скажешь. :(

Меня впечатляет документация - https://www.postgresql.org/docs/current/static/rules.html

A rule has significantly more overhead than a trigger, but the overhead is paid once per query rather than once per row, so this method might be advantageous for bulk-insert situations. In most cases, however, the trigger method will offer better performance.

https://www.postgresql.org/docs/9.6/static/ddl-partitioning.html отсюда

Меня впечатляет документация - https://www.postgresql.org/docs/current/static/rules.html

Впечатлитесь: https://www.postgresql.org/docs/current/static/rules-update.html ;) А SELECT RULE строго равны VIEW, кстати.

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

?

Впечатлитесь: https://www.postgresql.org/docs/current/static/rules-update.html ;) А SELECT RULE строго равны VIEW, кстати.

Да, я в курсе. Уже лет 8 как ?

Триггеры на VIEW появились относительно недавно.

Раньше правила были необходимыми, чтобы модифицировать таблицы через виды.

Я согласен что в большинстве случаев триггеры: проще, быстрее, понятнее.

Я согласен что в большинстве случаев триггеры: проще, быстрее, понятнее.

Ну а вот разработчики PostgreSQL считают, что правильно написать нетривиальное RULE невозможно. ;) А какой от тривиальных-то толк?

Триггеры на VIEW появились относительно недавно.

В 9.1, правильно (я до этого, к счастью, PostgreSQL "всерьёз" не пользовался ;) )?

Ну а вот разработчики PostgreSQL считают, что правильно написать нетривиальное RULE невозможно. ;) А какой от тривиальных-то толк?

Что же мешает разработчикам PostgreSQL выпилить возможность определения правил пользователями? Хитрый план какой-то? Что-то я не улавливаю логики.

обратная совместимость, например

обратная совместимость, например

Т.е. пользователи есть и о них разработчики заботятся?

Время умопомрачительных открытий.

Что же мешает разработчикам PostgreSQL выпилить возможность определения правил пользователями? Хитрый план какой-то? Что-то я не улавливаю логики.

Обратная совместимость, я так понимаю. Кроме того, вдруг кто-то придумает, как их нормально реализовать... Помните историю с hash-индексами, например? Я вот думал, что их в самом деле выпилят, а оно вон как вышло. ;)

Т.е. пользователи есть и о них разработчики заботятся?

Политика проекта такая. Это, кстати, далеко не единственная возможность, которую очень советуют не использовать.

Вы, видимо, далеки от разработки софта. Если какая-то фича признаётся разработчиком плохо спроектированной, то она обяъвляется устаревшей (deprecated) или через 1-2 релиза выпилывается. RULES в Постгресе со времен его создания - никто об этом даже не думает.

Вы, видимо, далеки от разработки софта. Если какая-то фича признаётся разработчиком плохо спроектированной, то она обяъвляется устаревшей (deprecated) или через 1-2 релиза выпилывается. RULES в Постгресе со времен его создания - никто об этом даже не думает.

> Вы, видимо, далеки от разработки софта. Да ладно Вам. ;) > Если какая-то фича признаётся разработчиком плохо спроектированной, то она обяъвляется устаревшей (deprecated) или через 1-2 релиза выпилывается. Покажите мне кучу выпиленных features в PostgreSQL. С очень большим трудом там всё удаляется. (Там даже в некоторых случаях dead code болтается годами (в надежде "а вдруг пригодится", и ничего.) > RULES в Постгресе со времен его создания - никто об этом даже не думает. То есть, все ссылки (на тех, кто думает) Вы проигнорировали? ;)

Вы, видимо, далеки от разработки софта. Если какая-то фича признаётся разработчиком плохо спроектированной, то она обяъвляется устаревшей (deprecated) или через 1-2 релиза выпилывается. RULES в Постгресе со времен его создания - никто об этом даже не думает.

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

ну и которым 20 лет, да

Вы, видимо, далеки от разработки софта. Если какая-то фича признаётся разработчиком плохо спроектированной, то она обяъвляется устаревшей (deprecated) или через 1-2 релиза выпилывается. RULES в Постгресе со времен его создания - никто об этом даже не думает.

Ах да, кстати про выпиливание плохо спроектированных features: если какая-то, хотя бы откровенно идиотская и вредная (а их есть) пришла из ISO SQL, она останется в PostgreSQL навсегда (или до тех пор, пока её не выпилят из стандарта). Писать bug reports и дискутировать бесполезно, такие дела. ;)

> Вы, видимо, далеки от разработки софта. Да ладно Вам. ;) > Если какая-то фича признаётся разработчиком плохо спроектированной, то она обяъвляется устаревшей (deprecated) или через 1-2 релиза выпилывается. Покажите мне кучу выпиленных features в PostgreSQL. С очень большим трудом там всё удаляется. (Там даже в некоторых случаях dead code болтается годами (в надежде "а вдруг пригодится", и ничего.) > RULES в Постгресе со времен его создания - никто об этом даже не думает. То есть, все ссылки (на тех, кто думает) Вы проигнорировали? ;)

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

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

Я не понял вопроса.

Ах да, кстати про выпиливание плохо спроектированных features: если какая-то, хотя бы откровенно идиотская и вредная (а их есть) пришла из ISO SQL, она останется в PostgreSQL навсегда (или до тех пор, пока её не выпилят из стандарта). Писать bug reports и дискутировать бесполезно, такие дела. ;)

Как всё печально. Они ели кактус и плакали, плакали но ели кактус.

Ой, холи вар ещё идёт))

Ой, холи вар ещё идёт))

Ага, время офигительных историй продолжается. Кругом антипаттерны и антиперфекционизм.

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

> Вы дали ссылки на частный бложик То есть, Вы не знаете, чей этой "частный бложик" и кто там комментирует? ;) Вам рассказать? > и на вики. Которую нынче могут редактировать только... угадайте кто? Вы авторов этой статьи посмотрели? > А я просто показал Вам документацию Постгреса, где чёрным по белому говорится о крутости правил в Постгресе. Да, про SELECT-ы. А я всё это время писал не о них! > Это официальная документация, а не вики или бложик. В которой тоже есть аналогичное предупреждение. > Вы сравниваете огурец с пальцем. ORLY? ;)

> Вы дали ссылки на частный бложик То есть, Вы не знаете, чей этой "частный бложик" и кто там комментирует? ;) Вам рассказать? > и на вики. Которую нынче могут редактировать только... угадайте кто? Вы авторов этой статьи посмотрели? > А я просто показал Вам документацию Постгреса, где чёрным по белому говорится о крутости правил в Постгресе. Да, про SELECT-ы. А я всё это время писал не о них! > Это официальная документация, а не вики или бложик. В которой тоже есть аналогичное предупреждение. > Вы сравниваете огурец с пальцем. ORLY? ;)

Мне глубоко безразлично чей это блог и кто там комментирует.

Как всё печально. Они ели кактус и плакали, плакали но ели кактус.

Именно так. :( Вы уверены, что знаете, на что ориентируются разработчики PostgreSQL?

Вики - это не документация. И совершенно неважно кто её может править.

Хоть сам Стоунбрейкер.

Мне глубоко безразлично чей это блог и кто там комментирует.

А зря, зря... Я бы на Вашем месте поинтересовался.

А зря, зря... Я бы на Вашем месте поинтересовался.

Ну Вы бы на моём месте и RULES бы не использовали. Причём тут я? Мои что-ли проблемы это? Нет.

А зря, зря... Я бы на Вашем месте поинтересовался.

А можно без увиливаний, для тех кто не в теме прямо написать? Чей блог?

Вики - это не документация. И совершенно неважно кто её может править.

И, опять-таки, важно. > Хоть сам Стоунбрейкер. Только этого не хватало — он-то и придумал большую часть этих "гениальных" features. :(

И, опять-таки, важно. > Хоть сам Стоунбрейкер. Только этого не хватало — он-то и придумал большую часть этих "гениальных" features. :(

Хахаха.

Лол.

А можно без увиливаний, для тех кто не в теме прямо написать? Чей блог?

А Вы разве спрашивали? ;) Blog этот Andrew Gierth (committer), комментирует там Tom Lane (основной разработчик PostgreSQL).

Том - один из ключевых. Никакой он не основной.

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

Сказки рассказываете.

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

Но Вы умнее, по-ходу ?