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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
