On Tue, Apr 27, 2021 at 6:59 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > On Tue, Apr 27, 2021 at 12:23 PM Amul Sul <sula...@gmail.com> wrote: > > > > > > How about using an explain filter to replace the unstable text > > > pg_temp_3 to pg_temp_N instead of changing it in the core? Following > > > are the existing explain filters: explain_filter, > > > explain_parallel_append, explain_analyze_without_memory, > > > explain_resultcache, explain_parallel_sort_stats, explain_sq_limit. > > > > > > > Well, yes eventually, that will be the kludge. I was wondering if that > > table is accessible in a query via pg_temp schema then why should > > bother about printing the pg_temp_N schema name which is an internal > > purpose. > > Although only the associated session can access objects from that > schema, I think, the entries in pg_class have different namespace oids > and are accessible from other sessions. So knowing the actual schema > name is useful for debugging purposes. Using auto_explain, the explain > output goes to server log, where access to two temporary tables with > the same name from different sessions can be identified by the actual > schema name easily. > > I am not sure whether we should change explain output only for the > sake of stable tests.
I agree to not change the explain code, just for tests. > You could add a flag to EXPLAIN to mask pg_temp name but that's > probably an overkill. IMO, you are right, it will be an overkill. We might end up having requests to add flags for other cases as well. > Filtering is a better option for tests. +1. EXPLAIN output filtering is not something new, we have already stabilized a few tests. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com