On 2016-09-12 19:35:22 -0400, Tom Lane wrote:
> >> You're inventing objections.
>
> > Heh, it's actually your own objection ;)
> > http://archives.postgresql.org/message-id/32673.1464023429%40sss.pgh.pa.us
>
> I'm changing my opinion in the light of unfavorable evidence. Is that
> wrong?
Nah, not at all. I was just referring to "inventing".
> > I wonder how much duplication we'd end up between nodeFunctionscan.c and
> > nodeSRF (or whatever). We'd need the latter node to support ValuePerCall
> > in an non-materializing fashion as well. Could we combine them somehow?
>
> Yeah, I was wondering that too. I doubt that we want to make one node
> type do both things --- the fact that Result comes in two flavors with
> different semantics (with or without an input node) isn't very nice IMO,
> and this would be almost that identical case.
It might not, agreed. That imo has to be taken into acount calculating
the code costs - although the executor stuff usually is pretty boring in
comparison.
> But maybe they could share
> some code at the level of ExecMakeTableFunctionResult. (I've not looked
> at your executor changes yet, not sure how much of that still exists.)
I'd split ExecMakeTableFunctionResult up, to allow for a percall mode,
and that seems like it'd still be needed to avoid performance
regressions.
It'd be an awfully large amount of code those two nodes would
duplicate. Excepting different rescan logic and ORDINALITY support,
nearly all the nodeFunctionscan.c code would be needed in both nodes.
> Anyway I'll draft a prototype and then we can compare.
Ok, cool.
Andres