> >> Sorry. I think the current version is better than previous one. The >> term "subselect alias" is confusing in the previous version. In the >> current version, "Get the relation and column alias for a given Var >> node," we need to add word "identifiers" like "Get the relation and >> column identifiers for a given Var node". > > > OK, but one thing I'm concerned about is the term "relation alias" seems a > bit confusing because we already used the term for the alias of the form > "rN". To avoid that, how about saying "table alias", not "relation alias"? > (in which case, the comment would be something like "Get the table and > column identifiers for a given Var node".)
table will be misleading as subquery can represent a join and corresponding alias would represent the join. Relation is better term. > > >> If we deparse from and search into different objects, that's not very >> maintainable code. Changes to any one of them require changes to the >> other, thus creating avenues for bugs. Even if slighly expensive, we >> should search into and deparse from the same targetlist. > > > I don't think so; in the current version, we essentially deparse from and > search into the same object, ie, foreignrel->reltarget->exprs, since the > tlist created by build_tlist_to_deparse is build from the > foreignrel->reltarget->exprs. Also, since it is just created for deparsing > the relation as a subquery in deparseRangeTblRef and isn't stored into > fpinfo or anywhere alse, we would need no concern about creating such > avenues. IMO I think adding comments would be enough for this. 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. -- 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
