> > >>>> build_tlist_to_depase() calls pull_var_nodes() before creating the >>>> tlist, whereas the code that searches does not do that. Code-wise >>>> those are not the same things. > > >>> You missed the point; the foreignrel->reltarget->exprs doesn't contain >>> any >>> PHVs, so the tlist created by build_tlist_to_depase will be guaranteed to >>> be >>> one-to-one with the foreignrel->reltarget->exprs. > > >> It's guaranteed now, but can not be forever. This means anybody who >> supports PHV tomorrow, will have to "remember" to update this code as >> well. If s/he misses it, a bug will be introduced. That's the avenue >> for bug, I am talking about. > > > It *can* be guaranteed. See another patch for supporting evaluating PHVs > remotely.
We can't base assumptions in this patch on something in the other patch, esp. when that's not even reviewed once. PHV is just one case, subqueries involving aggregates is other and there are others. But that's not really the point. The point is add_to_flat_tlist(pull_var_clause(rel->reltarget->exprs) can not be proved to be same as rel->reltarget->exprs in general. So, we should base our code on an assumption that can not be proved. -- 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
