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

[hydrobiont.livejournal.com]

Или я не понял твой мессадж, или ты только что изобрел тест Тьюринга ;-)

Ну да - посгресовый sql вместе с CTE - тьюринг полный язык и на нем можно сделать что угодно. Ну да - pl/pgsql - тоже вестимо. И что?)

[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).

[sergey konoplev (from livejournal.com)]

EXECUTE 'SELECT * FROM ' || blabla, например. Парируйте ;)

[astarsan.livejournal.com]

Я был уверен что NO EXECUTE стояло в постановке задачи.
Судя по всему пропустил этот пункт.
Уже добавил.

Это естественно не реализуется.

PS: кстати коственная адресация к полю таблицы по имени заданому в другой таблице на уровне sql делается через hstore при необходимости (через hstore(table_row)->other_table.field
(http://www.postgresql.org/docs/9.1/interactive/hstore.html
с потерей информации о типе правда).