|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Changed SRF in targetlist handling|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2016-08-02 16:30:55 -0700, Andres Freund wrote:
> > > Besides that I'm structurally wondering whether turning the original
> > > query into a subquery is the right thing to do. It requires some kind of
> > > ugly munching of Query->*, and has the above problem.
> > It does not seem like it should be that hard, certainly no worse than
> > subquery pullup. Want to show code?
> It's not super hard, there's some stuff like pushing/not-pushing
> various sortgrouprefs to the subquery. But I think we can live with it.
> Let me clean up the code some, hope to have something today or
Here we go. This *clearly* is a POC, not more. But it mostly works.
0001 - adds some test, some of those change after the later patches
0002 - main SRF via ROWS FROM () implementation
0003 - Large patch removing now unused code. Most satisfying.
The interesting bit is obviously 0002. What it basically does is, at the beginning
move the jointree into a subquery
process the old targetlist to reference the new subquery. If a
TargetEntry doesn't contain a set, it's entirely moved into the
subquery. Otherwise all Vars/Aggrefs/... it references are moved to
the subquery, and referenced in the outer query's target list.
Replace set returning functions in the targetlist with references to
a new FUNCTION RTE. All non-nested tSRFs are part of the same RTE
(i.e. the least common multiple behaviour is gone). all tSRFs in
arguments are implemented as another FUNCTION RTE.
I discovered that we allow SRFs in UPDATE target lists. It's not clear
to me what that's supposed to mean. Nor how exactly to implement that,
given expand_targetlist(). Right now that fails with the patch, because
it re-inserts Var's for the relation replaced by the subquery.
Note that I've not bothered to fix up the regression test output - I'm
certain that explain output and such will still change.
Biggest questions / tasks:
* General approach
* DML handling
* Operator implementation
* SETOF record handling
* correct handling of lateral dependency from RTE to subquery to force
evaluation order, instead of my RangeTblEntry->deps hack.
* lot of cleanup
|Next Message||Noah Misch||2016-08-04 04:14:20||Re: [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)|
|Previous Message||Claudio Freire||2016-08-04 01:24:58||Re: Lossy Index Tuple Enhancement (LITE)|