Refactor parser's generation of Var nodes.
Instead of passing around a pointer to the RangeTblEntry that
provides the desired column, pass a pointer to the associated
ParseNamespaceItem. The RTE is trivially reachable from the nsitem,
and having the ParseNamespaceItem allows access to additional
information. As proof of concept for that, add the rangetable index
to ParseNamespaceItem, and use that to get rid of RTERangeTablePosn
searches.
(I have in mind to teach the parser to generate some different
representation for Vars that are nullable by outer joins, and
keeping the necessary information in ParseNamespaceItems seems
like a reasonable approach to that. But whether that ever
happens or not, this seems like good cleanup.)
Also refactor the code around scanRTEForColumn so that the
"fuzzy match" stuff does not leak out of parse_relation.c.
Discussion: https://postgr.es/m/26144.1576858373@sss.pgh.pa.us
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/b541e9accb28c90656388a3f827ca3a68dd2a308
Modified Files
--------------
src/backend/parser/analyze.c | 10 +-
src/backend/parser/parse_clause.c | 23 ++-
src/backend/parser/parse_expr.c | 105 ++++++------
src/backend/parser/parse_func.c | 12 +-
src/backend/parser/parse_node.c | 21 ---
src/backend/parser/parse_relation.c | 314 ++++++++++++++++++++++--------------
src/backend/parser/parse_target.c | 85 +++++-----
src/include/parser/parse_node.h | 8 +-
src/include/parser/parse_relation.h | 43 ++---
9 files changed, 332 insertions(+), 289 deletions(-)
