Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Дата | |
Msg-id | 21924.1484593998@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling)
Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (wasChanged SRF in targetlist handling) |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > That worked quite well. So we have a few questions, before I clean this > up: > - For now the node is named 'Srf' both internally and in explain - not > sure if we want to make that something longer/easier to understand for > others? Proposals? TargetFunctionScan? SetResult? "Srf" is ugly as can be, and unintelligible. SetResult might be OK. > - I continued with the division of Labor that Tom had set up, so we're > creating one Srf node for each "nested" set of SRFs. We'd discussed > nearby to change that for one node/path for all nested SRFs, partially > because of costing. But I don't like the idea that much anymore. The > implementation seems cleaner (and probably faster) this way, and I > don't think nested targetlist SRFs are something worth optimizing > for. Anybody wants to argue differently? Not me. > Comments? Hard to comment on your other points without a patch to look at. regards, tom lane
В списке pgsql-hackers по дате отправления: