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. >> 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, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers