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.


Surafel Temesgen

On Tue, Jan 17, 2017 at 8:21 AM, Tom Lane <> wrote:

> Surafel Temsgen <> 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

Attachment: corresponding_clause_v1.patch
Description: Binary data

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to