Re: dropping a user causes pain (#2)

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: dropping a user causes pain (#2)
Дата
Msg-id 3F37AF26.1050602@dunslane.net
обсуждение исходный текст
Ответ на Re: dropping a user causes pain (#2)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: dropping a user causes pain (#2)  (Andreas Pflug <pgadmin@pse-consulting.de>)
Список pgsql-hackers
I did have a thought that it could be done lazily (on backend startup) 
on other databases and immediately on the current database. I guess it 
depends on the cost of checking for such things - wouldn't want to add 
greatly to startup time.

That would leave a small window of orphanage for existing backends on 
other databases, but is arguably an improvement on the current situation.

OTOH I'm not sure how much harm this causes, other than aesthetic.

andrew

Tom Lane wrote:

>"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>  
>
>>Ah OK, I must have been thinking of the database owner check.  I'd vote for
>>(1) checking that they own no objects and by default owning all their stuff
>>to the database owner.  Plus add an optional clause:
>>DROP USER foo OWNER TO bob;
>>    
>>
>
>If you can suggest a plausible way that DROP USER is going to change the
>contents of other databases (which might well contain things owned by
>the target user), this might get onto the TODO list --- although I'd
>personally prefer RESTRICT/CASCADE options.  So far, since no one has
>the foggiest idea how to implement cross-database removal, it's just
>been left as-is.
>
>            regards, tom lane
>
>  
>




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Oh, Speaking of users and owning things....
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Farewell