причем его поведение может меняться в зависимости от типа аргументов

И эти люди запрещают нам ковыряться в носу использовать монгу, дефолты и орм...

Зачем это языку который достает данные???

затем что можно создавать свои типы и задавать на них операторы

Операторы на новых типах - это ок, примеру понятны, перемножение матриц или других сложных объектов. Так умеют многие языки.
Уточнение тогда - sql разрешает переопределить этот оператор на системных типах а-ля int float double?

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

тут смешались 2 вопроса.

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

сейчас ты хочешь группировать по x*2, потом по сложному выражению. базе придется научиться приводить все эти выражения.
это плохая идея :)

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

а третья часть - это просто не имеет физического смысла :)

это oracle style. в посгре известный как «стиль линвалео»

:)

А он так стал называться до статей на Хабре или после?

Ну я даже пост не смотрел, просто мой вопрос про то что ты сказал выше - можно ли переопределить умножение интов встроенных типов так чтобы они давали математически неправильный ответ?

Как известно, на хранимках постгреса можно написать POSIX-совместимую операционную систему.

после. но это неофициально :)

сейчас до компа доберусь

А что за статьи? Я как-то по ключу «линвалео» ничего не могу найти

хранимки пишутся не на sql, но кого это волнует )

Оправдан ли такой подход?

Надо по лингвалео

Их статьи

Ты прав в части "один метод". Это я перепутал подход к созданию application и domain services.

Значит ли это, что чморить хранимки можно безнаказанно?