> > > > If you plan to hold support SRFin target list, then nothing is different. > In last patch is executed under nodeProjectSet.
It is, because we suddenly need to call different functions - and I'm revamping most of execQual to have an opcode dispatch based execution model (which then also can be JITed).
> > > XMLTABLE is specified by the standard to return multiple rows ... but > > > then as far as my reading goes, it is only supposed to be supported in > > > the range table (FROM clause) not in the target list. I wonder if > > > this would end up better if we only tried to support it in RT. I asked > > > Pavel to implement it like that a few weeks ago, but ... > > > > Right - it makes sense in the FROM list - but then it should be an > > executor node, instead of some expression thingy. > > > > The XMLTABLE function is from user perspective, from implementation > perspective a form of SRF function. I use own executor node, because fcinfo > is complex already and not too enough to hold all information about result > columns.
> The implementation as RT doesn't reduce code - it is just moving to > different file.
You're introducing a wholly separate callback system (TableExprRoutine) for the new functionality. And that stuff is excruciatingly close to stuff that the normal executor already knows how to do.
These callbacks are related to isolation TableExpr infrastructure and TableExpr implementation - This design is prepared for reusing for JSON_TABLE function.
Any placing of TableExpr code should not impact this callback system (Or I am absolutely out and executor is able do some work what is hidden to me).
> I'll try to explain my motivation. Please, check it and correct me if I am > wrong. I don't keep on my implementation - just try to implement XMLTABLE > be consistent with another behave and be used all time without any > surprise. > > 1. Any function that produces a content can be used in target list. We > support SRF in target list and in FROM part. Why XMLTABLE should be a > exception?
targetlist SRFs were a big mistake. They cause a fair number of problems code-wise. They permeated for a long while into bits of both planner and executor, where they really shouldn't belong. Even after the recent changes there's a fair amount of uglyness associated with them. We can't remove tSRFs for backward compatibility reasons, but that's not true for XMLTABLE
ok
I afraid when I cannot to reuse a SRF infrastructure, I have to reimplement it partially :( - mainly for usage in "ROWS FROM ()"