Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema - Mailing list pgsql-hackers

At Wed, 25 Dec 2019 11:22:03 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> Anyway, as dropping a temporary schema leads to an inconsistent
> behavior when recreating new temporary objects in a session that
> dropped it, that nobody has actually complained on the matter, and
> that in concept a temporary schema is linked to the session that

Agreed.

> created it, I think that we have a lot of arguments to just forbid the
> operation from happening.  Please note as well that it is possible to
> drop temporary schemas of other sessions, still this is limited to
> owners of the schema.
> 
> In short, let's tighten the logic, and we had better back-patch this
> one all the way down, 9.4 being broken.  Attached is a patch to do
> that.  The error message generated depends on the state of the session
> so I have not added a test for this reason, and the check is added
> before the ACL check.  We could make the error message more generic,
> like "cannot drop temporary namespace".  Any thoughts?

Just inhibiting the action seems reasonable to me.

Still the owner can drop temporary namespace on another session or
pg_toast_temp_x of the current session.

isTempnamespace(address.objectId) doesn't work for the purpose.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center