Andres Freund wrote: > 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? > > - We could alternatively add all this into the Result node - it's not > actually a lot of new code, and most of that is boilerplate stuff > about adding a new node. I'm ok with both.
Hmm. I wonder if your stuff could be used as support code for XMLTABLE[1]. Currently it has a bit of additional code of its own, though admittedly it's very little code executor-side. Would you mind sharing a patch, or more details on how it works? [1] https://www.postgresql.org/message-id/cafj8pra_keukobxvs4v-imoeesxu0pd0ashv0-mwrfdrwte...@mail.gmail.com > - 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? Nested targetlist SRFs make my head spin. I suppose they may have some use, but where would you really want this: alvherre=# select generate_series(1, generate_series(2, 4)); generate_series ───────────────── 1 2 1 2 3 1 2 3 4 (9 filas) instead of the much more sensible alvherre=# select i, j from generate_series(2, 4) i, generate_series(1, i) j; i │ j ───┼─── 2 │ 1 2 │ 2 3 │ 1 3 │ 2 3 │ 3 4 │ 1 4 │ 2 4 │ 3 4 │ 4 (9 filas) ? If supporting the former makes it harder to support/optimize more reasonable cases, it seems fair game to leave them behind. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
