|From:||Surafel Temsgen <surafel3000(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: New CORRESPONDING clause design|
|Views:||Raw Message | Whole Thread | Download mbox|
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.
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
> > name
> > in The corresponding column list appears in column names of both
> > *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
|Next Message||Simon Riggs||2017-02-16 15:03:54||Re: Partitioning vs ON CONFLICT|
|Previous Message||Thom Brown||2017-02-16 14:54:00||Partitioning vs ON CONFLICT|