Re: Why is materialized view creation a "security-restricted operation"? - Mailing list pgsql-general

From Thiemo Kellner
Subject Re: Why is materialized view creation a "security-restricted operation"?
Date
Msg-id 3edf72d9-94d2-4de9-89d9-fbd456525265@gelassene-pferde.biz
Whole thread
In response to Re: Why is materialized view creation a "security-restricted operation"?  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: Why is materialized view creation a "security-restricted operation"?
List pgsql-general
I am referring to "Temporary tables are automatically dropped at the end of a session, or optionally at the end of the current transaction" (https://www.postgresql.org/docs/18/sql-createtable.html). I.e that if you have to debug a production system, you cannot just look into the temptables to to pin-point where data is not the way expected. You have to recreate every intermediary result.

04.10.2026 22:24:47 Adrian Klaver <adrian.klaver@aklaver.com>:

On 10/4/26 12:27 PM, Thiemo Kellner wrote:
Hi
Giving my two dimes. I apologise if some else has given it already. And it is quite an operations point of view and mostly based on Oracle. To the best of my knowledge, it applies to Postgres even more.
The data of DB temp tables are not visible outside of the session that has put it in. In the case of trying to find the problem of code of functions storing intermediary results, they are just not visible for the investigator such that one has to do all the steps manually to detect the point where things go wrong. In my opinion a real pita.

I am not quite following the above.

Do you mean:

1) Not having access to the function code ?

2) Having access to function code, but not the source of data?




Cheers
Thiemo


--
Adrian Klaver
adrian.klaver@aklaver.com

pgsql-general by date:

Previous
From: Juan Rodrigo Alejandro Burgos Mella
Date:
Subject: Re: libpq analog of \c
Next
From: Färber, Franz-Josef (StMUK)
Date:
Subject: AW: Why is materialized view creation a "security-restricted operation"?