Re: Changed SRF in targetlist handling

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Changed SRF in targetlist handling
Date: 2016-08-04 03:22:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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
of subquery_planner():
1) unsrfify:
move the jointree into a subquery
2) unsrfify_reference_subquery_mutator:
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.
3) unsrfify_implement_srfs_mutator:
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



Andres Freund

Attachment Content-Type Size
0001-Add-some-more-targetlist-srf-tests.patch text/x-patch 8.3 KB
0002-Basic-implementation-of-targetlist-SRFs-via-ROWS-FRO.patch text/x-patch 27.6 KB
0003-Remove-now-unused-tSRF-code.patch text/x-patch 117.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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)