Kerem Kat <kerem...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
