AW: Why is materialized view creation a "security-restricted operation"?

Yes, I would have to predefine the columns.
In my case it's just one column, one row, which i wanted to load from an external file.

Regards,
Franz-Josef Färber

-----Ursprüngliche Nachricht-----
Von: Rob Sargent <robjsargent(at)gmail(dot)com>
Gesendet: Dienstag, 13. Oktober 2026 17:37
An: Färber, Franz-Josef (StMUK) <Franz-Josef(dot)Faerber(at)stmuk(dot)bayern(dot)de>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>; Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>; pgsql-general(at)postgresql(dot)org; Haupt, Matthias (StMUK) <Matthias(dot)Haupt(at)stmuk(dot)bayern(dot)de>
Betreff: Re: Why is materialized view creation a "security-restricted operation"?

> On Oct 13, 2026, at 08:17, Färber, Franz-Josef (StMUK) <Franz-Josef(dot)Faerber(at)stmuk(dot)bayern(dot)de> wrote:
>
> 
>>
>> Well, you want to use a materialized view for something that it cannot be used for, for security reasons. We tried to explain that in this thread.
> Yes, you can see it this way: One way would be: Using Temp Tables. This way is blocked due to security reasons. Discussion finished.
>
> Another point of view is:
> 0) The security problem is not inherent for what I was trying to archieve; but due to lack of expressiveness one is forced into this dead end.
> 1) Either: Postgres' COPY stmt lacks the ability to omit the physical table, something like SELECT * FROM COPY FROM ...
> 2) or: Postgres lacks table variables.
>

I am not clear on your workflow so these questions come to mind:
What do you do with the undefined “*” (if it were allowed)?
Would you not have to predefine the columns of the table variable?