Re: BUG #18251: Incorrect DROP VIEW pg_catalog.* behavior
От | Julien Rouhaud |
---|---|
Тема | Re: BUG #18251: Incorrect DROP VIEW pg_catalog.* behavior |
Дата | |
Msg-id | ZX7qpJHzRyoKzqai@jrouhaud обсуждение исходный текст |
Ответ на | BUG #18251: Incorrect DROP VIEW pg_catalog.* behavior (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
Hi, On Sun, Dec 17, 2023 at 09:44:33AM +0000, PG Bug reporting form wrote: > > When i try to drop and create system view, i get following behavior: > > postgres=# DROP VIEW pg_catalog.pg_config; > DROP VIEW > > postgres=# CREATE OR REPLACE VIEW pg_catalog.pg_config AS > SELECT pg_config.name, pg_config.setting > FROM pg_config() pg_config(name, setting); > ERROR: permission denied to create "pg_catalog.pg_config" > DETAIL: System catalog modifications are currently disallowed. That's somewhat expected. System catalog modifications are only prevented globally at the creation side, I guess mostly because we don't want user to e.g. create an index or a trigger on a system catalog just to realize that it won't be maintained, and things like that. The fact that you can drop a system view is because you're using a superuser connection, and there are so many things you can do as a superuser to mess up the instance so there wouldn't be much value disallowing just this specific case. > > I'm not sure, but it's look strange. > When i connect to template1, i can use droped views. But if drop view on > template1 problem repeats. That's not surprising. You always need to use a database to create a new one. The only different between a template database and a normal database is the permissions needed on the source database side.
В списке pgsql-bugs по дате отправления: