Re: dropping a user causes pain (#2)
От | Christopher Kings-Lynne |
---|---|
Тема | Re: dropping a user causes pain (#2) |
Дата | |
Msg-id | 189601c3606e$70b3b380$2800a8c0@mars обсуждение исходный текст |
Ответ на | dropping a user causes pain (#2) ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | pgsql-hackers |
> Not sure I care for the "vacuum" part of that, but how about this > variant: DROP USER sets a flag in pg_shadow to disable login, and > the pg_shadow entry isn't removed, ever. (We could tweak the pg_user > view to hide dropped users, but anything looking directly at pg_shadow > would have to be taught about the flag, analogous to what happened with > attisdropped in the last release.) > > The advantage here is that the sysid assigned to the user would remain > present in pg_shadow and couldn't accidentally be assigned to a new > user. This would prevent the problem of new users "inheriting" > permissions and even object ownership from deleted users due to chance > coincidence of sysid. > > I suppose one could delete the pg_shadow row once one is darn certain > there is no trace of the user's sysid anywhere, but it's not clear to me > it's worth the trouble. +1 (Hey I've seen other people do that :P ) Chris
В списке pgsql-hackers по дате отправления: