> I have just upgraded to PostgreSQL 8.1 and I have encountered the
> following problem. When I connect through psqlODBC 8.01.0200 (PostgreSQL
> Unicode), a sequence like the following:
>
> <start a transaction>
> DROP SEQUENCE BAZ;
> SELECT 1;
>
> will give an error on the DROP SEQUENCE:
>
> "42P01: Error while executing the query;
> ERROR: sequence "app_bod_seq" does not exist"
>
> and will then give an error on the SELECT 1:
>
> "25P02: Error while executing the query;
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block"
>
> When connecting through the psqlODBC 8.00.0102, I do *not* get the
> second error. This is, in fact, what I would expect. It is also what
> pretty much all other databases do (our application also runs on
> Informix, Firebird, Oracle and MS SQL Server, and they all allow failed
> commands in transactions without forcing a rollback). And it is what the
> 8.00.0102 driver did (or appeared to do?). Was this behaviour changed on
> purpose, and if so, why? And is there a way to work around it? ;-)
This is backend related. I assume you use autocommit=off. In this
case backend doesn't allow next commands after failed one in
one transaction.
08.00.0102 driver calls automatic rollback (if I remember it right).
Some users voted againist it. And I agreed with them. When programmer
manage the transaction he may also manage errors.
I see no reason to continue transaction when something in it failed.
Transaction may be atomic. All inside is ok or no change happens.
It sounds quite odd for me that another RDBMS do it another way.
Please could you explain it to me better? What behaviour do you expect
when fail second SQL command, ...
Regards,
Luf