On Sat, Sep 24, 2011 at 18:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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. >
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. Planner uses _corresponding ones if query is a corresponding query, view-definition-generator uses larg and rarg which represent the query user entered. Comments? > > 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. > 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? note: I am new to this list, am I asking too much detail? 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
