Hi,
On Thu, Jun 12, 2025 at 2:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniil Davydov <3danissimo@gmail.com> writes:
> > Ability to do a DROP temporary table of other session leads to error :
>
> [ shrug... ] Don't do that. A superuser is capable of doing lots
> of things that will break the database, and this one hardly seems
> like one of the worse ones.
OK, I see your point, thanks.
IMHO, deleting other temporary tables and (for example) deleting rows
from pg_class are not so similar in terms of the obvious occurrence of
bad consequences.
But as far as I understand, we will not specify such details somewhere
in the documentation.
>
> > BTW, there are other bugs that can occur during interacting with other
> > session temp tables. I described them and suggested corrections in
> > this thread [1].
>
> I doubt I'd agree that any such thing is a bug we need to fix.
> You should not be attempting to touch other sessions' temp tables.
> (If there's any path by which a non-superuser can do that, we
> probably need to tighten some permission check somewhere.)
Let's forget about DROP for a while. Postgres design has rules, that
superuser cannot perform commands like
select/update/delete/truncate... with other session's temp tables.
You can find appropriate error messages (for example) in bufmgr.c :
***
if (RELATION_IS_OTHER_TEMP(reln))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot access temporary tables of other sessions")));
***
But by now the query parser does not recognize other session's temp
tables as temporary, and we can get weird query results instead of
getting the error provided by the postgres design (that even worse
than unexpected error occurrence).
I am sure that this is a bug and we should fix such behavior.
--
Best regards,
Danill Davydov
