> ... because PostgreSQL is more statically typed ... > You might not think of that as a feature, but it's the way PostgreSQL works. I disagree.
It is not a statically-typing problem. My use case would easily be feasible if ... * ... the PostgreSQL COPY ... FROM PROGRAM statement could be used like a query, without having to use a temp table. Due to typing, one would have to use a FROM clause with column names and types defined, just like tablefunc: https://www.postgresql.org/docs/current/tablefunc.html * ... or there would be some chance to create a temp table inside a plpgsql function ... which in the end is used in my use case inside a materialized view ... which is forbidden and which can still be seen in the subject of this mail as the first question I had. Regards, Franz-Josef Färber -----Ursprüngliche Nachricht----- Von: Christophe Pettus <[email protected]> Gesendet: Dienstag, 13. Oktober 2026 08:34 An: Färber, Franz-Josef (StMUK) <[email protected]> Cc: Adrian Klaver <[email protected]>; [email protected] Betreff: Re: Why is materialized view creation a "security-restricted operation"? > On Oct 12, 2026, at 23:23, Färber, Franz-Josef (StMUK) > <[email protected]> wrote: > > Yes, Thank you. I mentioned that here, with its disadvantage: > https://www.postgresql.org/message-id/f69b47dbbe374bac8088887c21193f26%40stmuk.bayern.de > : I'm not sure why scripting CREATE FOREIGN TABLE is that complex, but you know your application best. PostgreSQL cannot easily do what DuckDB does and just have a .csv thrown at it as a table, because PostgreSQL is more statically typed than DuckDB, and would need a way to be told what types the columns are. You might not think of that as a feature, but it's the way PostgreSQL works. PostgreSQL is not the right tool for every single job, and this may be a case where a different data engine will suit you better.
