Skip site navigation (1) Skip section navigation (2)

Re: Adding CORRESPONDING to Set Operations

From: Kerem Kat <keremkat(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding CORRESPONDING to Set Operations
Date: 2011-09-24 16:24:16
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Sat, Sep 24, 2011 at 18:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kerem Kat <keremkat(at)gmail(dot)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:

Planner uses _corresponding ones if query is a corresponding query,
uses larg and rarg which represent the query user entered.


> > 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?


Kerem KAT

In response to


pgsql-hackers by date

Next:From: Andres FreundDate: 2011-09-24 16:26:10
Subject: Re: posix_fadvsise in base backups
Previous:From: Robert HaasDate: 2011-09-24 16:14:31
Subject: Re: unite recovery.conf and postgresql.conf

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group