"Peter Haworth" wrote:
> You can do it with one check:
>
> try
> if( ! update table x )
> insert into table x
> commit
> catch all
> rollback
> print error messge
That's correct for the actual example. The problem is: we have many,
many constructions like this in our application, and want to prevent
their adaption for PostgreSQL. Further on we use this in lower level
libraries, which can't make assupmtions about the transactional state or
commit/rollback the actual transaction.
> Surely your application ought to know whether it should be doing an insert
> or an update anyway?
This can easy be done by setting flags, with or without usage of
exception handling. A common case for my example is an import program,
which transparently inserts new or updates existing rows.
Besides this it is much faster to assume, that the row can be inserted,
and only seldomly do special things if this fails, as always execute a
SQL command for checking on existence, which normally always will fail,
thus I have to regularly execute two statements instead of one.
It works with every database I know, but not with PostgreSQL. Whose
transaction model is right?
Joern
--
Joern Reder -- Software Development, dimedis GmbH, 50672 Koeln
http://www.dimedis.de/ http://spirit.dimedis.de/
supporting: http://www.zyn.de/ http://www.netcologne.de/~nc-joernre/
CPAN: http://www.perl.com/CPAN/modules/by-module/CIPP/JRED/
