Petro123koltsЛучше без промежуточных результатов? Почему?
странный вопрос. Почему быстрее считать в уме, чем записывать промежуточно на бумажку?
Базовое понятие в БД - кортеж
http://citforum.ru/database/osbd/glava_16.shtml
По другому это на аппСервере с ООП и в другом ЯП
вообще--то будь в пг реализована табличная переменная с передачей по ссылке -- это тоже было бы "вычисление в уме" без записи--писи.

но её нет. и это не просто печалька, это боль.

передача массивов или жейсонов не вариант --- так как всякий раз передаётся копия (якобы внутре передача по ссылке, но т.к. "исходное" может лежать на диске -- быть полем записи таблицы -- заботимся, якобы, чтобы не переписать помимо апдейта)=> всякое [каждое] изменение такого "объекта" -- полное копирование с пришиванием рюшечки. даже если в цыкле. даже если объявили переменную сами, руками (вот тут вроде бы и можно вычислить, что она уж точно не "поле на диске") . Хотя внутре "c" оно возможно сделать экономнее -- см. string_agg array_agg и т.п. агрегаты. там где передача ссылки на агрегат через internal переменную.

что--то можно в plperl и т.п. [pltcl/plpython/..] -- совсем не надо никаких левых аппСерверов -- в перле вполне себе и хеш--таблички и массивы имеются. и передача ссылок на них. только вот пёрл -- язык типа для любителей брейн--факкинга.
ну и в "true c" , для умельцев не попадать в ногу, стреляя в неё в упор.

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

но её нет. и это не просто печалька, это боль.


Это не печалька, а осознанное решение!
SQL - декларативный ЯП.
Хочешь императивщину иди в "песочницу".

Этим PostgreSQL мне и нравится.
Что SQL там SQL, а не FoxPro. ;-)много же вас, , путающих декларативность с немощью.

чем задание виртуальной таблицы - т.е. табличной переменной, мешает декларативности?
[ну введите декларативное CREATE LOCAL IN MEMORY TABLE [USING BLOCK ENGINE], если такие упоротые. я не против.] (/*для блокировочника перезапись по месту -- не криминал*/).
осознанно только геморойность реализации -- есть такой паттерн -- "зелёный виноград" . у дедушки крылова хорошо описан.
замечательно освоен разрабами пж. примеров -- завались. не будем о грустном. им денех не плотют. да и не миллион индусов там. жалко их.

к тому же и речь -- не об собственно SQL , а о пл ПгСкл -- вот это вот "пл" ничего не говорит декларанто--фапперам/шликкерам?

Petro123qwwqвообще--то будь в пг реализована табличная переменная с передачей по ссылке -- это тоже было бы "вычисление в уме" без записи--писи.
было озвучено "что лучше" без конкретной задачи.
- лучше мыть руки перед едой
- лучше sql чем курсор
- в крайнем случае используем курсор
- потом временная таблица в оперативке на коннект (есть?)
- потом постоянная бумажка для записи (таблица постоянная)
Есть это в PosgreSQL?
а говорили, что "дети у нас хорошие ..."
а выглядите -- как руками сделанные

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

пока же всё -- через одно место, после которого руки таки лучше мыть
и блаародных донов, считающих что всё делать через это место -- труеЪ декларейшн увей -- хоть уделайся
печалька, йоптель


остаётся что-то серьёзное (серьёзно агрегирующее или серьёзно перевычислительное) делать на не срьёзных языках, типа пл--перла