Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Rob Sargent <robjsargent@gmail.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Why is materialized view creation a "security-restricted
 operation"?
Date: Tue, 13 Oct 2026 09:36:47 -0600
Message-Id: <9B7D623E-1DEF-46DC-92B3-FF9452624F5C@gmail.com>
References: <3b50a3393fd84d56b40cfddd67c98dbc@stmuk.bayern.de>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
 Adrian Klaver <adrian.klaver@aklaver.com>, pgsql-general@postgresql.org,
 Matthias Haupt <Matthias.Haupt@stmuk.bayern.de>
In-Reply-To: <3b50a3393fd84d56b40cfddd67c98dbc@stmuk.bayern.de>
To: =?utf-8?Q?Franz-Josef_F=C3=A4rber?= <Franz-Josef.Faerber@stmuk.bayern.de>
Archived-At: 
 <https://www.postgresql.org/message-id/9B7D623E-1DEF-46DC-92B3-FF9452624F5C%40gmail.com>
Precedence: bulk


> On Oct 13, 2026, at 08:17, F=C3=A4rber, Franz-Josef (StMUK) <Franz-Josef.Fa=
erber@stmuk.bayern.de> wrote:
>=20
> =EF=BB=BF
>>=20
>> 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 wa=
y is blocked due to security reasons. Discussion finished.
>=20
> 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 tabl=
e, something like SELECT * FROM COPY FROM ...
> 2) or: Postgres lacks table variables.
>=20

I am not clear on your workflow so these questions come to mind:
What do you do with the undefined =E2=80=9C*=E2=80=9D (if it were allowed)? =
=20
Would you not have to predefine the columns of the table variable?=