Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

At Wed, 25 Dec 2019 11:22:03 +0900, Michael Paquier <michael(at)paquier(dot)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