Re: CREATE USER

I tryed many variations of BEGIN, COMMINT, CREATE USER .... and ROLLBACK,
but none of them worked, I always get the same error message (CREATE USER:
may not be called in a transaction block).
So, is possible to do what I want to?
I think that in 6.5.3 I could, but now in 7.0 is not working, I'm right??
I'm running an application from win machines via ODBC, so is more difficult
to execute a operating system command like CREATEUSER that would be a
solution. So, would be perfect to me to do it via SQL commands.
Sorry about my poor english!

Diego Schvartzman
Email: diego(dot)schvartzman(at)usa(dot)net
ICQ# 1779434
----- Original Message -----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>; Lista PGSQL
<pgsql-general(at)postgresql(dot)org>; Diego Schvartzman <dschvar(at)yahoo(dot)com>
Sent: Thursday, June 01, 2000 3:45 AM
Subject: Re: [GENERAL] CREATE USER

> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
>