Here is the implementation of the clause with the slight change, instead of doing column mapping for each side of leaf Queries in planner I make the projection nodes output to corresponding column lists only.
This patch compiles and tests successfully with master branch on ubuntu-15.10-desktop-amd64.It also includes documentation and new regression tests in union.sql.
Regards
Surafel Temesgen
On Tue, Jan 17, 2017 at 8:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Surafel Temsgen <surafel3000@gmail.com> writes: > My design is > *In parsing stage* > 1. Check at least one common column name appear in queries > 2. If corresponding column list is not specified, then make corresponding > list from common column name in queries target lists in the order > that those column names appear in first query > 3. If corresponding column list is specified, then check that every column > name > in The corresponding column list appears in column names of both queries > *In planner* > 1. Take projection columen name from corresponding list > 2. Reorder left and right queries target lists according to corresponding > list > 3. For each query, project columens as many as number of corresponding > columen.
FWIW, I think you need to do most of that work in the parser, not the planner. The parser certainly has to determine the actual output column names and types of the setop construct, and we usually consider that the parsing stage is expected to fully determine the semantics of the query. So I'd envision the parser as emitting some explicit representation of the column mapping for each side, rather than expecting the planner to determine for itself what maps to what.
It probably does make sense for the actual implementation to involve inserting projection nodes below the setop. I'm pretty sure the executor code for setops expects to just pass input tuples through without projection. You could imagine changing that, but it would add a penalty for non-CORRESPONDING setops, which IMO would be the wrong tradeoff.
