"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> How about starting new transaction automatically after committing
> "create user ..." at backend side if "create user" is the first command
> of the transaction ?
So then
begin;
create user ...;
rollback;
would do the wrong thing --- silently?
I don't think that's an improvement :-(
The only reason CREATE USER isn't rollbackable is that the flat password
file is updated immediately by a trigger, rather than at transaction
commit. The right fix would be to defer the update until commit (which
is certainly doable, though it might mean hardwired support for the
update instead of doing it in a generic trigger function).
If that seems like too much work, how about downgrading the "create
user not allowed in transaction" error to a "please don't abort now"
notice? It's pretty silly that CREATE USER is stiffnecked about this
when DROP TABLE is not --- the bad consequences of rolling back DROP
TABLE are a lot worse.
regards, tom lane