Robert Haas <robertmh...@gmail.com> writes:
> Gee, I would have expected the DROP to be blocked until the user
> disconnected, like we do for DROP DATABASE.
Making that race-condition-free would require some notion of a lock on
roles, I think. Seems pretty messy compared to the amount of actual
value obtained. There are good reasons why you can't have a backend
running in a nonexistent database; but a backend with a nonexistent
user OID is not really going to be a problem for anything except
monitoring queries that fail to use left joins where appropriate.
Even if we maintained some interlock for a backend's login role identity,
I hardly think it would be practical to e.g. lock during transient SET
ROLE or security-definer-function-call operations. So it's not like we
can let the permissions system assume that a role OID being inquired about
always matches a live entry in pg_authid.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
