Skip site navigation (1) Skip section navigation (2)

Re: patch: streaming of bytea parameter values

From: Kris Jurka <books(at)ejurka(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: patch: streaming of bytea parameter values
Date: 2004-05-23 21:23:37
Message-ID: Pine.BSO.4.56.0405231441080.5428@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-jdbc

On Sun, 23 May 2004, Oliver Jowett wrote:

> Kris Jurka wrote:
> > On Sun, 23 May 2004, Oliver Jowett wrote:
> >>
> >>I don't see what isn't cleaned up by closing the connection. It seems 
> >>the simplest and safest way of handling this sort of error.
> > 
> This is a bit different in that we can always detect it. You never end 
> up with a hosed connection that the driver will try to continue using.
> 
> Being user-friendly when dealing with application errors is nice 
> behaviour to have, but it *is* a separate issue..

Separate from what, correctness?  We both agree that a short stream or 
IOException is an error, but I'm not advocating the JDBC equivalent of 
System.exit() as a viable solution.  What makes it OK for this 
particular error to destroy a Connection while no other application level 
error can?

> 
> > This is more of a general problem with the JDBC driver
> > in that if it throws an Exception itself it does not require a rollback
> > while server generated errors do.  Perhaps this should be added to the
> > drivers query issuing/commit logic to refuse to proceed if the driver has
> > thrown an error.
> 
> If you're talking about all the exceptions that can ever be thrown by 
> the driver, it sounds like unnecessary complexity to me,
> 
> It makes sense for exceptions thrown during query execution though, Are 
> there currently any cases where the driver can throw an exception from 
> query execution without invalidating the current transaction?
> 

I am unsure what you mean by "query execution."  From a user's perspective
the moment they say PreparedStatement.execute() query execution has begun
and in that case the Exception that comes to mind is the check to make
sure all parameters of a PreparedStatement have been set.  See
QueryExecute.sendQueryV3.  From a driver perspective query execution 
begins when it issues pgStream.SendChar('Q') or similar and I believe the 
only Exception that should be thrown there in the current code is an 
IOException on the stream which is fatal to the connection in any case.

Kris Jurka

In response to

Responses

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2004-05-23 22:17:20
Subject: Re: patch: streaming of bytea parameter values
Previous:From: Kris JurkaDate: 2004-05-23 21:07:35
Subject: Re: getBlob and setBlob on OID columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group