Re: New CORRESPONDING clause design

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Surafel Temsgen <surafel3000(at)gmail(dot)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
>