On Mon, Sep 25, 2006 at 05:40:56PM +0530, Gurjeet Singh wrote: > >In this case > >PostgreSQL does the right thing; something went wrong, queries after the > >error may very well depend on that data - you can't rely on the current > >state. And it's what the SQL specs say too, of course... > > In an automated/programmatic access to the database, this might be > desirable; but when there's someone manually doing some activity, it sure > does get to one's nerves if the transaction till now was a long one. > Instead, the operator would love to edit just that one query and fire again! Well, psql does it just that way. It implements auto-commit on behalf of the user unless a transaction is explicitely started. > Also, in automated/programmatic access, the programs are supposed to > catch the error and rollback/correct on their own. Sure but that of course does not relieve the database of aborting the transacation on its own as soon as something goes wrong. And for sake of efficiency the transaction should be aborted right there and then and subsequent queries can be ignored until the end of transaction. This is easier on CPU cycles and memory consumption. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
