Re: 12 to 13 migration, the privs error with pg_pltemplate
От | Scott Ribe |
---|---|
Тема | Re: 12 to 13 migration, the privs error with pg_pltemplate |
Дата | |
Msg-id | F1D171AD-F02C-4D78-8152-11329B21E372@elevated-dev.com обсуждение исходный текст |
Ответ на | Re: 12 to 13 migration, the privs error with pg_pltemplate (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: 12 to 13 migration, the privs error with pg_pltemplate
|
Список | pgsql-admin |
> On Dec 11, 2020, at 1:36 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Yes, I specifically asked if you were looking at the correct database > previously, because it matters: At that time I thought I had run the original REVOKE command in the target database, and then tried ALTER DEFAULT PRIVILEGESin postgres. I was probably mistaken. > I'm pretty sure none of this has anything to do with DEFAULT PRIVILEGES > as those only actually apply when a new table is created (and not from a > template database), and that's just never the case with any PG catalog > tables. So the fact that default privs were set on the system catalogs was inappropriate, but harmless in this case? > What might be useful to point out is that only a superuser can change > the privileges associated with PG catalog tables and that you really > should be careful who you grant superuser privileges to. Yes, that's one thing I took care of earlier this year: change our processes such that we were able to remove superuser fromthe commonly-used service accounts.
В списке pgsql-admin по дате отправления: