Какво е очакваното поведение за множество функции, връщащи набор в клауза SELECT?

Postgres 10 или по-нова версия

добавя нулеви стойности за по-малки набори. Демо с generate_series() :

SELECT generate_series( 1,  2) AS row2
     , generate_series(11, 13) AS row3
     , generate_series(21, 24) AS row4;
 

dbfiddle тук

Ръководството за Postgres 10 :

Ако има повече от една функция за връщане на набор в списъка за избор на заявката, поведението е подобно на това, което получавате от поставянето на функциите в един LATERAL ROWS FROM( ... ) FROM - клауза елемент. За всеки ред от основната заявка има изходен ред, използващ първия резултат от всяка функция, след това изходен ред, използващ втория резултат и т.н. Ако някои от функциите за връщане на набор произвеждат по-малко резултати от други, нулевите стойности се заменят с липсващите данни, така че общият брой на излъчените редове за един основен ред е същият като за функцията за връщане на набор, която е произвела най-много резултати. По този начин функциите за връщане на набори се изпълняват „последователно“, докато всички не бъдат изчерпани, а след това изпълнението продължава със следващия подлежащ ред.

Това слага край на традиционно странното поведение.

Postgres 9.6 или по-стара версия

Броят на редовете с резултати (донякъде изненадващо!) е най-ниското общо кратно от всички набори в същия SELECT списък. (Действа само като CROSS JOIN ако няма общ делител за всички размери на набора!) Демо:

SELECT generate_series( 1,  2) AS row2
     , generate_series(11, 13) AS row3
     , generate_series(21, 24) AS row4;
 

dbfiddle тук

Документирано в ръководство за Postgres 9.6 глава SQL функции, връщащи набори , заедно с препоръката да го избягвате:

Забележка:Основният проблем с използването на функции за връщане на набори в списъка за избор, а не в FROM клауза е, че поставянето на повече от функция за връщане на един набор в един и същ списък за избор не се държи много разумно. (Това, което всъщност получавате, ако го направите, е брой изходни редове, равен на най-малкото общо кратно на броя на редовете, произведени от всяка функция за връщане на набор. ) LATERAL синтаксисът дава без изненадващи резултати при извикване на множество функции за връщане на набор и обикновено трябва да се използва вместо това.

Удебелен акцент мой.

Една функция за връщане на набор е ОК (но все пак по-чиста в FROM). списък), но множество в един и същ SELECT списъкът е обезкуражен сега. Това беше полезна функция, преди да имаме LATERAL се присъединява. Сега това е просто исторически баласт.

Свързано:

• Паралелна unnest() и ред на сортиране в PostgreSQL
• Отвържете паралелно множество масиви
• Каква е разликата между LATERAL JOIN и подзаявка в PostgreSQL?