The docs (new and old) explicitly state you can do this; see for example
http://www.postgresql.org/docs/7.3/static/sql-dropuser.html
But ISTM that in such a case the user's objects should possibly be
reassigned to the database owner (who can't be dropped), in kinda the
same way that a *nix
Tom Lane writes:
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
Andreas Pflug [EMAIL PROTECTED] 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,
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?
Andrew Dunstan wrote:
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
Christopher Kings-Lynne [EMAIL PROTECTED] 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
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: 11 August 2003 04:02
To: Andrew Dunstan; Hackers
Subject: Re: [HACKERS] dropping a user causes pain (#2)
DROP USER foo OWNER TO bob;
Isn't that a bit tricky as foo might own objects in other
Andrew Dunstan writes:
Makes sense, but I think DROP USER should also warn immediately if it
detects the most common case (I imagine) where the user owns things in
the current database.
Well, the dropuser program connects to template1, so in that case it'd
be a rather uncommon occurrence.
--
Christopher Kings-Lynne 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.
The reason none of this will work is that users are global, so when you
drop a user,
ISTM there's a difference between an object without an (exisiting) owner
and an object whose owner doesn't currently have the privileges required
to create it, although maybe there's a good case for a script to detect
the latter as a part of a good administrator's arsenal of tricks in
keeping
Makes sense, but I think DROP USER should also warn immediately if it
detects the most common case (I imagine) where the user owns things in
the current database.
andrew
Bruce Momjian wrote:
If people want to remove a user, I assume they don't want to keep
old objects around.
How about if we
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
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
[EMAIL PROTECTED]
To: Hackers [EMAIL PROTECTED]
Sent: Monday, August 11, 2003 10:49 AM
Subject: Re: [HACKERS] dropping a user causes pain (#2)
The docs (new and old) explicitly state you can do this; see for example
http://www.postgresql.org/docs/7.3/static/sql-dropuser.html
But ISTM
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
Hi,
I dropped the owner of a table (with no complaints), and now I get this:
psql:
asdf=# \dt
List of relations
Schema | Name | Type | Owner
+--+---+
public | a1 | table |
pg_dump:
pg_dump: WARNING: owner of data type a1 appears to be invalid
16 matches
Mail list logo
