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".

I wrote:
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 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.

Best regards,
Etsuro Fujita

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to