RE: JDBC Drop/Create problem?

--
Peter Mount
Enterprise Support Officer, Maidstone Borough Council
Email: petermount(at)maidstone(dot)gov(dot)uk
WWW: http://www.maidstone.gov.uk
All views expressed within this email are not the views of Maidstone Borough
Council

> -----Original Message-----
> From: Joachim Achtzehnter [mailto:joachim(at)kraut(dot)ca]
> Sent: Monday, December 11, 2000 5:29 PM
> To: pgsql-interfaces(at)postgresql(dot)org
> Subject: RE: [INTERFACES] JDBC Drop/Create problem?
>
>
> Today, in a message to pgsql-interfaces, Peter Mount wrote:
> >
> > The problem JDBC has is that it's DatabaseMetaData methods can make
> > several queries. While AutoCommit is off, if one of those fails, the
> > users transaction will also fail.
>
> If the JDBC driver under the hood performs several queries in
> response to
> a single 'user command' and one of these fails it can still
> report that
> command's failure without aborting the whole transaction (assuming the
> backend supports statement-level aborts, of course).

Unless 7.1 now supports statement level aborts (and it's possible I've
missed it if it has) this is where the problem lies. The backend currently
does abort the whole transaction.

Peter

Today, in a message to pgsql-interfaces, Peter Mount wrote:
>
> Unless 7.1 now supports statement level aborts (and it's possible I've
> missed it if it has) this is where the problem lies. The backend
> currently does abort the whole transaction.

Exactly. I was speaking about postgresql in general, not JDBC specificly.
In my previous email I was merely pointing out that if postgresql, i.e.
the backend, did support statement-level aborts (which it doesn't
currently) then JDBC could too. There are no special JDBC issues that
would require aborting the whole transaction.

Joachim

--
work: joachima(at)realtimeint(dot)com (http://www.realtimeint.com)
private: joachim(at)kraut(dot)ca (http://www.kraut.ca)