DKIM2-Signature: i=1; m=1; t=1791323409; d=aklaver.com;
	mf=PGFkcmlhbi5rbGF2ZXJAYWtsYXZlci5jb20+;
	rt=PHBnc3FsLWdlbmVyYWxAbGlzdHMucG9zdGdyZXNxbC5vcmc+;
	s=fm1:rsa-sha256:RpWrMQ9zEqOabZiYOU713KJJIQdWjnruwfZ19Aly19N8DXZ
	Tmpt3lc9i0yiu8FGWA1hDWS+YPVPE/z4n3UfWA0AbR3aS4tXW5yhD9LHinJEsWB8
	YqB7kkimDeYPrS37EjzA9zEkU9e9VhTu9H0RGQNhQAGmrSiJnu0eWifOq4RqPUg/
	Oxs3WH1vA+hE8d/WVapQLYl1rLgPF2zmFzk902KHOPGhfxeyaYJ4jh0Z+ksoNZyd
	juOQ1vEBxHYXYWL59XHKQ7iqLkK1B4wD53+2PcKxqJTIdUnmiKNVL9tj0M5KiE+4
	ZDsOQDT4X4EpabcH6XncPPLHwq+QHVUtfoCYXsQ==;
Message-Instance: m=1;
 h=sha256:R7B0T94U3jxeu3fuGJfpi6C//93HCWDfJ5iWizzrxdo=:GCUMk5M1u64COiOQHp3yTPoZNSXUPsybNOQuY/fVj2E=;
Feedback-ID: i76984098:Fastmail
Message-ID: <f9e87c52-45b3-49df-9f5d-6cf1fb4c5bbd@aklaver.com>
Date: Tue, 6 Oct 2026 14:50:03 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Why is materialized view creation a "security-restricted
 operation"?
To: Thiemo Kellner <thiemo@gelassene-pferde.biz>,
 pgsql-general <pgsql-general@lists.postgresql.org>
References: <77826d7580a9488ca28eb4bcfe94aa37@stmuk.bayern.de>
 <9da33cfb-661f-4088-9fad-04f6eb8fd21b@gelassene-pferde.biz>
 <e26681b8-695d-45d4-9359-af12ce33dcfe@aklaver.com>
 <3edf72d9-94d2-4de9-89d9-fbd456525265@gelassene-pferde.biz>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <3edf72d9-94d2-4de9-89d9-fbd456525265@gelassene-pferde.biz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/f9e87c52-45b3-49df-9f5d-6cf1fb4c5bbd%40aklaver.com>
Precedence: bulk


On 10/5/26 11:02 PM, Thiemo Kellner wrote:
> 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.

Does that issue not also exist with persistent tables, where the data 
you are looking in the debugging stage maybe not be what was present at 
the error stage?


> 
> 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