Re: patch: function xmltable

> > >
> >
> > 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
>