pg_temp_%d namespace creation can invalidate all the cached plan in other backends

Planning is expensive and we use plancache to bypass its effect. I find the
$subject recently which is caused by we register NAMESPACEOID invalidation
message for pg_temp_%s as well as other normal namespaces. Is it a
must?

We can demo the issue with the below case:

Sess1:
create table t (a int);
prepare s as select * from t;
postgres=# execute s;
INFO: There is no cached plan now
a
---
(0 rows)

postgres=# execute s; -- The plan is cached.
a
---
(0 rows)

Sess2:
create temp table m (a int);

Sess1:

postgres=# execute s; -- The cached plan is reset.
INFO: There is no cached plan now
a
---
(0 rows)

What I want to do now is bypass the invalidation message totally if it is a
pg_temp_%d
namespace. (RELATION_IS_OTHER_TEMP). With this change, the impact is not
only
the plan cache is not reset but also all the other stuff in
SysCacheInvalidate/CallSyscacheCallbacks will not be called (for pg_temp_%d
change
only). I think pg_temp_%d is not meaningful for others, so I think the
bypassing is OK.
I still have not kicked off any coding so far, I want to know if it is a
correct thing to do?

--
Best Regards
Andy Fan (https://www.aliyun.com/)