> > > Ashutosh proposed this to do the comparison: > > On 2016/11/22 18:28, Ashutosh Bapat wrote: >> >> I guess, the reason why you are doing it this way, is SELECT clause for >> the >> outermost query gets deparsed before FROM clause. For later we call >> deparseRangeTblRef(), which builds the tlist. So, while deparsing SELECT >> clause, we do not have tlist to build from. In that case, I guess, we have >> to >> build the tlist in get_subselect_alias_id() if it's not available and >> stick it >> in fpinfo. Subsequent calls to get_subselect_alias_id() should find tlist >> there. Then in deparseRangeTblRef() assert that there's a tlist in fpinfo >> and use it to build the SELECT clause of subquery. That way, we don't >> build >> tlist unless it's needed and also use the same tlist for all searches. >> Please >> use tlist_member() to search into the tlist. > > > This would probably work, but seems to me a bit complicated. Instead, I'd > like to propose that we build the tlist for each relation being deparsed as > a subquery in a given join tree, right before deparsing the SELECT clause in > deparseSelectStmtForRel, if is_subquery is false and lower_subquery_rels > isn't NULL, and store the tlist into the relation's fpinfo. That would > allow us to build the tlist only when we need it, and to use tlist_member > for the exact comparison. I think it would be much easier to implement > that. >
IIRC, this is inline with my original proposal of creating tlists before deparsing anything. Along-with that I also proposed to bubble this array of tlist up the join hierarchy to avoid recursion [1] point #15, further elaborated in [2] [1] https://www.postgresql.org/message-id/ad449b25-66ee-4c06-568c-0eb2e1bef9f9%40lab.ntt.co.jp [2] https://www.postgresql.org/message-id/CAFjFpRcn7%3DDNOXm-PJ_jVDqAmghKVf6tApQC%2B_RgMZ8tOPExcA%40mail.gmail.com We seem to be moving towards that solution, but as discussed we have left it to committer's judgement. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
