Surafel Temsgen <surafel3...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers