Re: New CORRESPONDING clause design

From: Surafel Temsgen <surafel3000(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: New CORRESPONDING clause design
Date: 2017-02-16 14:58:52
Message-ID: CALAY4q-GodM3H+PvJ-dUQTLp__=wrKy+jKWvJpaHaLeZGoaP=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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
>

Attachment Content-Type Size
corresponding_clause_v1.patch application/octet-stream 56.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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