Re: Adding CORRESPONDING to Set Operations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kerem Kat <keremkat(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding CORRESPONDING to Set Operations
Date: 2011-09-24 16:51:58
Message-ID: 9828.1316883118@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

>> 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, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-24 17:01:38 Re: unite recovery.conf and postgresql.conf
Previous Message Tom Lane 2011-09-24 16:46:59 Re: Large C files