TX semantics backward compatibility

From: Kovács Péter <peter(dot)kovacs(at)chemaxon(dot)hu>
To: pgsql-general(at)postgresql(dot)org
Subject: TX semantics backward compatibility
Date: 2005-06-23 16:05:33
Message-ID: 42BADDCD.1010607@chemaxon.hu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

We've got a product which supposedly supports the major RDBMSs including
PostgreSQL. We tested it so far only with PostgreSQL 7.2 and found no
problem. Now, it turned out that it does not work with more recent
versions (certainly not with 8.0). The problem is with the kind of code
where we test the existence of a table in a transaction with:

select count(*) from doesitexist where 1 = 2;

If there is an error, we assume that the table does not exists and go
ahead without rollback and commit. When later we issue an SQL statement
again, we get the error message you probably all know.

Of course, we rely on we-do-not-exactly-now-how-many places on a
transaction still being usable after a (read-only) statement level error.

Is it correct that the behaviour in this regard was different with
earlier versions (like with 7.2)? (I.e. a statement level error left you
with a still usable transaction?) Or have we introduced some subtle
change into our code (or our testing environment) which makes the
difference? Or may something have changed in the client driver we use
(JDBC)? Is there a simple way to revert to the old behaviour in this regard?

Many thanks in advance,

Peter

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Fuhr 2005-06-23 16:19:39 Re: plpgsql constraint checked data fails to restore
Previous Message Jan Wieck 2005-06-23 15:47:37 Re: plpgsql constraint checked data fails to restore