select only хранимки vs old plain sql

[astarsan]

По итогам последних развлечений с sql
У меня сложилась гипотеза что любой скольугодно сложный код на pl/pgsql который
1)не меняет данные и не использует locks/exceptions
2)не работает с курсорами
3)не использует честную рекурсию
UPDATE: 4)не использует EXECUTE так как это очевидно на уровне SQL не реализуется

может быть переделан в виде обычного sql запроса.
Насколько финальный sql запрос будет читаем - вопрос отдельный.
С другой стороны он может оказаться быстрее.

временные таблицы - array[] of records или with подзапросы
циклы - with recursive iterator
if/then - case
вроде ничего из pl/pgsql логики не осталось больше.

Скорее всего это не так но я не смог придумать контрпример.
Так что жду ваши версии select only pl/pgsql кода которые нельзя реализовать обычным запросом.

PS: не надо только 4х страничные хранимки присылать... я думаю если контрпример есть, то он будет коротким и понятным.

Comments

[astarsan.livejournal.com]

Я как то раньше не думал о том что SQL это "тьюринг полный язык" на самом деле. Потому и возник вопрос.
Я до этого считал что есть куча алгоритмов которые нельзя нормально на sql сделать.

[hydrobiont.livejournal.com]

Как много нам открытий чудных))

[smagen.livejournal.com]

По-моему все-таки "тьюринг полный язык" != "можно нормально сделать любой алгоритм". Т.к. "нормально" подразумевает вменяемые время выполнения и объем требуемой памяти, а из-за особенностей реализации языка это может быть не так.

[astarsan.livejournal.com]

Через with recursive очень невыгодно по обьему требуемой памяти гонять длинные циклы (там потребление памяти линейное от количества итераций) поэтому любой алгоритм на pl/pgsql с длинными (и тем более с длинным вложенными) циклами если его не удасться переделать на with/join а прийдется честно делать через with recurvise эффективно работать не будет к сожалению.

Самый первый пришедший в голову пример - сортировка элементов массива (сделанная любым честным алгоритмом а не через array(unnest(..) order by).