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
