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 17:10:43
Message-ID: CAJZSWkWK+u13UMdDWAkyKJUf3n8JNDOUYCHcADt71NXXero+cQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Sep 24, 2011 at 19:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kerem Kat <keremkat(at)gmail(dot)com> writes:
>> 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.
>
> Why?  CORRESPONDING at a given set-operation level doesn't affect either
> sub-query, so I don't see why you'd need a different representation for
> the sub-queries.
>

In the planner to construct a subquery out of SetOperationStmt or
RangeTblRef, a new RangeTblRef is needed.
To create a RangeTableRef, parser state is needed and planner assumes
root->parse->rtable be not modified
after generating simple_rte_array.

SELECT a,b,c FROM t is larg
SELECT a,b FROM (SELECT a,b,c FROM t) is larg_corresponding
SELECT d,a,b FROM t is rarg
SELECT a,b FROM (SELECT d,a,b FROM t); is rarg_corresponding

In the planner choose _corresponding ones if the query has corresponding.

SELECT a,b FROM (SELECT a,b,c FROM t)
UNION
SELECT a,b FROM (SELECT d,a,b FROM t);



>>> 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?
>
> No.  All that you're doing is correctly computing the lists of the
> set-operation's output column types (and probably names too).  These are
> internal details that needn't be examined when printing the query, so
> they won't affect ruleutils.c.
>
>> note: I am new to this list, am I asking too much detail?
>
> Well, I am beginning to wonder if you should choose a smaller project
> for your first venture into patching Postgres.
>


regards,

Kerem KAT

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-09-24 17:17:58
Subject: Re: Large C files
Previous:From: Peter GeogheganDate: 2011-09-24 17:10:38
Subject: Re: Large C files

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