I wrote: > So my feeling is: if we think this is the behavior we want, let's do > it across the board. I suggest that we simply drop the relid from the > jumble and use the table alias (that is, eref->aliasname) instead.
I experimented with this trivial fix (shown in-line to keep the cfbot from thinking this is the patch-of-record): diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h index 23c9e3c5abf..a54bbdc18b7 100644 --- a/src/include/nodes/parsenodes.h +++ b/src/include/nodes/parsenodes.h @@ -1051,7 +1051,7 @@ typedef struct RangeTblEntry /* user-written alias clause, if any */ Alias *alias pg_node_attr(query_jumble_ignore); /* expanded reference names */ - Alias *eref pg_node_attr(query_jumble_ignore); + Alias *eref; RTEKind rtekind; /* see above */ @@ -1094,7 +1094,7 @@ typedef struct RangeTblEntry * tables to be invalidated if the underlying table is altered. */ /* OID of the relation */ - Oid relid; + Oid relid pg_node_attr(query_jumble_ignore); /* inheritance requested? */ bool inh; /* relation kind (see pg_class.relkind) */ This caused just one diff in existing regression test cases: diff --git a/contrib/pg_stat_statements/expected/planning.out b/contrib/pg_stat_statements/expected/planning.out index 3ee1928cbe9..c25b8b946fd 100644 --- a/contrib/pg_stat_statements/expected/planning.out +++ b/contrib/pg_stat_statements/expected/planning.out @@ -75,8 +75,9 @@ SELECT plans >= 2 AND plans <= calls AS plans_ok, calls, rows, query FROM pg_sta WHERE query LIKE 'SELECT COUNT%' ORDER BY query COLLATE "C"; plans_ok | calls | rows | query ----------+-------+------+-------------------------------------- - t | 4 | 4 | SELECT COUNT(*) FROM stats_plan_test -(1 row) + f | 1 | 1 | SELECT COUNT(*) FROM stats_plan_test + f | 3 | 3 | SELECT COUNT(*) FROM stats_plan_test +(2 rows) -- Cleanup DROP TABLE stats_plan_test; What's happening there is that there's an ALTER TABLE ADD COLUMN in the test, so the executions after the first one see more entries in eref->colnames and come up with a different jumble. I think we probably don't want that behavior; we only want to jumble the table name. So we'd still need the v3-0001 patch in some form to allow annotating RangeTblEntry.eref with a custom jumble method that'd only jumble the aliasname. regards, tom lane