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 <t...@sss.pgh.pa.us> wrote: > Surafel Temsgen <surafel3...@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. > > regards, tom lane >
corresponding_clause_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
