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