From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dropping a user causes pain (#2) |
Date: | 2003-08-11 21:22:14 |
Message-ID: | 200308112122.h7BLMEf01097@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
If people want to remove a user, I assume they don't want to keep
old objects around.
How about if we created a script that goes through all the databases and
reports items owned by a specific user, or orphaned items not owned by
anyone?
---------------------------------------------------------------------------
Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> > Andrew Dunstan wrote:
> >> OTOH I'm not sure how much harm this causes, other than aesthetic.
> >>
> > Dropping a user could merely set a "dropped" flag to disable login, and
> > some VACUUM action could cleanup databases.
>
> 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.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2003-08-11 21:37:49 | Re: dropping a user causes pain (#2) |
Previous Message | Rod Taylor | 2003-08-11 20:53:37 | Oversight? |