On Sat, Sep 24, 2011 at 19:51, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kerem Kat <kerem...@gmail.com> writes: >> In the parser while analyzing SetOperationStmt, larg and rarg needs to be >> transformed as subqueries. SetOperationStmt can have two fields representing >> larg and rarg with projected columns according to corresponding: >> larg_corresponding, >> rarg_corresponding. > > Why? CORRESPONDING at a given set-operation level doesn't affect either > sub-query, so I don't see why you'd need a different representation for > the sub-queries. >
In the planner to construct a subquery out of SetOperationStmt or RangeTblRef, a new RangeTblRef is needed. To create a RangeTableRef, parser state is needed and planner assumes root->parse->rtable be not modified after generating simple_rte_array. SELECT a,b,c FROM t is larg SELECT a,b FROM (SELECT a,b,c FROM t) is larg_corresponding SELECT d,a,b FROM t is rarg SELECT a,b FROM (SELECT d,a,b FROM t); is rarg_corresponding In the planner choose _corresponding ones if the query has corresponding. SELECT a,b FROM (SELECT a,b,c FROM t) UNION SELECT a,b FROM (SELECT d,a,b FROM t); >>> Obviously, that logic doesn't work at all for CORRESPONDING, so you'll >>> need to have a separate code path to deduce the output column list in >>> that case. > >> If the output column list to be determined at that stage it needs to >> be filtered and ordered. >> In that case aren't we breaking the non-modification of user query argument? > > No. All that you're doing is correctly computing the lists of the > set-operation's output column types (and probably names too). These are > internal details that needn't be examined when printing the query, so > they won't affect ruleutils.c. > >> note: I am new to this list, am I asking too much detail? > > Well, I am beginning to wonder if you should choose a smaller project > for your first venture into patching Postgres. > regards, Kerem KAT -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
