Re: Changed SRF in targetlist handling
Vik Fearing <vik@2ndquadrant.fr>
From: Vik Fearing <vik@2ndquadrant.fr>
To: "David G. Johnston" <david.g.johnston@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Merlin Moncure <mmoncure@gmail.com>,
David Fetter <david@fetter.org>, Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-06T16:40:05Z
Lists: pgsql-hackers
On 06/06/16 18:30, David G. Johnston wrote: > To clarify, the present behavior is basically a combination of both of > Robert's results. > > If the SRFs return the same number of rows the first (zippered) result > is returned without an NULL padding. > > If the SRFs return a different number of rows the LCM behavior kicks in > and you get Robert's second result. No. > SELECT generate_series(1, 4), generate_series(1, 4) ORDER BY 1, 2; > is the same as > SELECT * FROM ROWS FROM ( generate_series(1, 4), generate_series(1, 4) ); > > BUT > > SELECT generate_series(1, 3), generate_series(1, 4) ORDER BY 1, 2; > is the same as > SELECT * FROM ROWS FROM generate_series(1, 3) a, LATERAL ROWS FROM > generate_series(1, 4) b; What would you do with: SELECT generate_series(1, 3), generate_series(1, 6); ? > Tom's 2.5 proposal basically says we make the former equivalence succeed > and have the later one fail. > > The rewrite would be unaware of the cardinality of the SRF and so it > cannot conditionally rewrite the query. One of the two must be chosen > and the incompatible behavior turned into an error. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Commits
-
Remove obsoleted code relating to targetlist SRF evaluation.
- ea15e18677fc 10.0 landed
-
Doc: improve documentation of new SRF-in-tlist behavior.
- f13a1277aa2d 10.0 landed
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 landed
-
Don't split up SRFs when choosing to postpone SELECT output expressions.
- d543170f2fdd 9.6.0 cited