Re: query_id: jumble names of temp tables for better pg_stat_statement UX

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