On 2016/11/24 16:46, Ashutosh Bapat wrote:
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.
But the documentation uses the word "table" for a join relation. See
126.96.36.199. Table and Column Aliases:
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.
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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: