| From: | Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)SE> |
|---|---|
| To: | Jose Soares <jose(at)sferacarta(dot)com> |
| Cc: | Wim Ceulemans <wim(dot)ceulemans(at)nice(dot)be>, "'general'" <pgsql-general(at)postgreSQL(dot)org> |
| Subject: | Re: [GENERAL] AW: [HACKERS] TRANSACTIONS |
| Date: | 2000-02-24 16:18:23 |
| Message-ID: | Pine.GSO.4.02A.10002241713480.17421-100000@Hummer.DoCS.UU.SE |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On Thu, 24 Feb 2000, Jose Soares wrote:
> NOTICE: (transaction aborted): all queries ignored until end of transaction block
>
> *ABORT STATE*
> Why PostgreSQL doesn't make an implicit ROLLBACK instead of waitting for a
> COMMIT/ROLLBACK ?
The PostgreSQL transaction paradigm seems to be that if you explicitly
start a transaction, you get to explicitly end it. This is of course at
odds with SQL, but it seems internally consistent to me. I hope that one
of these days we can offer the other behaviour as well.
> Why PostgreSQL allows a COMMIT in this case ?
Good question. I assume it doesn't actually commit though, does it? I
think a CHECK_IF_ABORTED (sp?) before calling the commit utility routine
would be appropriate. Anyone?
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
| From | Date | Subject | |
|---|---|---|---|
| Next Message | kaiq | 2000-02-24 16:29:58 | RE: [GENERAL] scheduling table design |
| Previous Message | Barnes | 2000-02-24 15:06:57 | RE: [GENERAL] scheduling table design |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Post Message | 2000-02-24 16:20:16 | Solid timer |
| Previous Message | Tom Lane | 2000-02-24 16:17:02 | Re: [HACKERS] Changes in 7.0 |