Kerem Kat <kerem...@gmail.com> writes: > There is a catch inserting subqueries for corresponding in the planner. > Parser expects to see equal number of columns in both sides of the > UNION query. If there is corresponding however we cannot guarantee that.
Well, you certainly need the parse analysis code to be aware of CORRESPONDING's effects. But I think you can confine the changes to adjusting the computation of a SetOperationStmt's list of output column types. It might be a good idea to also add a list of output column names to SetOperationStmt, and get rid of the logic that digs down into the child queries when we need to know the output column names. > Target columns, collations and types for the SetOperationStmt are > determined in the parser. If we pass the column number equality checks, > it is not clear that how one would proceed with the targetlist generation > loop which is a forboth for two table's columns. 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. 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