Hi,
On Mon, Mar 17, 2025 at 1:52 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> My understanding is the limitation of an owner of a temporary relation in one session being disallowed to alter its
contentsfrom another session is an implementation consequence, and not some fundamental model restriction.
I would say this: working with temporary tables (in the postgres
kernel) is so very different from working with regular heap tables
that such a limitation can be considered fundamental. We simply will
not be able to organize coordinated work on the temporary table from
different OS processes (for INSERT, UPDATE, DELETE).
> Minimally informed thinking, associate the specific pg_temp namespace with a procid. Where this limitation exists,
whichseems like middle management, compare the proc of the namespace to the executor. Pass the role and also an enum
ofaction type (CRUD, drop, truncate, lock, etc…). If the procs match all good. Superuser cannot bypass CRUD and
similaras that is the limitation being implemented here. And the owner cannot bypass anything (exceptions could be
addedas desired).
>
> Centralizing things a bit though…maybe something like the relcache (for namespaces…) so you cannot even get a handle
onthe namespace if you don’t supply the info and pass the checks. Don’t really know enough to say where/how to
implement“if you forget to call this check all commands that can reference tables will fail”.
I'm sorry, I probably don't quite understand what this is about, so
I'll just describe how it works now. If a superuser wants to access
other temp table, he must specify schema_name in request (for example
: INSERT INTO pg_temp_N.test .....). N is the id of the owner process.
Thus, postgres will call RangeVarGetRelidExtended to find the given
relation's oid. It is at this point that we can step in and check
whether the caller can work with the specified schema. It is
elementary to understand that the schema does belong to another
session. Right now, there is a bug in the code that mistakenly
recognizes the table in such a case as permanent (not temporary), so
we cannot do what I just described. So, we have to get rid of this bug
and decide whether we reserve the right for the superuser to DROP such
tables.
I hope this remark will be useful.
--
Best regards,
Daniil Davydov
