| From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | "Keary Suska" <hierophant(at)pcisys(dot)net> |
| Cc: | "Postgres General" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Unable to ALTER table after SELECT data from table |
| Date: | 2007-12-10 21:27:52 |
| Message-ID: | dcc563d10712101327we238a2ao27f3caaad4ece30d@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Dec 10, 2007 2:48 PM, Keary Suska <hierophant(at)pcisys(dot)net> wrote:
> on 12/10/07 12:15 PM, Thomas-Carsten(dot)Franke(at)brunel(dot)de purportedly said:
>
> > To work around this I add an dbCon.rollBack() after select statement
> > above in good and in bad times. After that ALTER works.
> > Can someone explain me why I need this rollback ?
>
> You only need the rollback when the SELECT statement fails. When an error
> occurs within a transaction, the transaction is aborted but not rolled back.
> There are likely reasons why the rollback isn't automatic, but I don't know
> them.
I think you confuse postgresql with some other database. Without
setting a savepoint, any error during a transaction and roll it back
upon connection close | rollback | commit.
I.e. the rollback IS automatic. Just not necessarily immediate.
> Your choice is either to run the commands in an "autocommit" mode or, as you
> are doing, rollback (or commit, if there was no error) after the SELECT.
You can commit with an error. It'll do the same thing as a rollback;
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hjenkins | 2007-12-10 21:31:42 | comparing rows |
| Previous Message | Martijn van Oosterhout | 2007-12-10 21:20:18 | Re: Unable to ALTER table after SELECT data from table |