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