2017-01-25 22:40 GMT+01:00 Andres Freund <and...@anarazel.de>: > Hi, > > > > > 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 ()" >
The TableExpr implementation is based on SRF now. You and Alvaro propose independent implementation like generic executor node. I am sceptic so FunctionScan supports reading from generic executor node. Regards Pavel > Huh? > > Greetings, > > Andres Freund >
