Re: CREATE USER
От | Diego Schvartzman |
---|---|
Тема | Re: CREATE USER |
Дата | |
Msg-id | 005b01bfcbfb$ccc733a0$e80a0a0a@redfed8 обсуждение исходный текст |
Ответ на | RE: CREATE USER ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Список | pgsql-general |
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.schvartzman@usa.net ICQ# 1779434 ----- Original Message ----- From: Tom Lane <tgl@sss.pgh.pa.us> To: Hiroshi Inoue <Inoue@tpf.co.jp> Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>; Lista PGSQL <pgsql-general@postgresql.org>; Diego Schvartzman <dschvar@yahoo.com> Sent: Thursday, June 01, 2000 3:45 AM Subject: Re: [GENERAL] CREATE USER > "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 >
В списке pgsql-general по дате отправления: