| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Thiemo Kellner <thiemo(at)gelassene-pferde(dot)biz>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Why is materialized view creation a "security-restricted operation"? |
| Date: | 2026-10-04 20:24:41 |
| Message-ID: | e26681b8-695d-45d4-9359-af12ce33dcfe@aklaver.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igor Korot | 2026-10-05 06:09:00 | libpq analog of \c |
| Previous Message | Thiemo Kellner | 2026-10-04 19:27:34 | Re: Why is materialized view creation a "security-restricted operation"? |