> > > > > > > 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 ()" Greetings, > > Andres Freund >
