On Sat, Sep 24, 2011 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Kerem Kat <keremkat@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