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

Re: [JDBC] BUG #5058: [jdbc] Silent failure with executeUpdate()

From: Kris Jurka <books(at)ejurka(dot)com>
To: Joseph Shraibman <jks(at)selectacast(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Subject: Re: [JDBC] BUG #5058: [jdbc] Silent failure with executeUpdate()
Date: 2009-09-26 14:32:19
Message-ID: alpine.BSO.2.00.0909261006130.2098@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-jdbc

On Thu, 17 Sep 2009, Joseph Shraibman wrote:

> [when passing a multi-statement sql string to executeUpdate, if a 
> statement after the first is a select, it is silently not fully
> executed.]

Running queries in executeUpdate is not allowed.  If you pass a plain 
select to executeUpdate it complains:  stmt.executeUpdate("SELECT 1");

org.postgresql.util.PSQLException: A result was returned when none was 
expected.

The problem here is that we don't complain if it's not the first part of a 
multi-part statement.  stmt.executeUpdate("/* */; SELECT 1") does not
produce an error, but should, which I believe is the bug in this case.

Since the JDBC driver knows it's going to complain if it sees a query 
result during executeUpdate, it wants to avoid the possibility of the user 
issuing a query which returns a giant dataset and having to process that 
just to error out anyway.  So it passes the statements to the server with 
an additional instruction to say, "I just want the first row back at this 
time".  That way if it is a big query result we'll only get one row 
instead of the whole thing.  The server can implement this by either 
holding the whole resultset on the server or, as in this case, partially 
executing the query and returning control to the driver to see if it wants 
to continue executing it.  So your select is only partially executed, 
getting run for only one row of the "joa" table rather than the whole 
thing as you are expecting.

I intend to change the driver to error out in this case.

Kris Jurka


In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-09-26 16:35:18
Subject: Re: BUG #5081: ON INSERT rule does not work correctly
Previous:From: Tom LaneDate: 2009-09-25 18:10:38
Subject: Re: Postgresql 8.4.1 segfault, backtrace

pgsql-jdbc by date

Next:From: Kris JurkaDate: 2009-09-26 14:38:00
Subject: Re: Support for getting generated keys.
Previous:From: Kris JurkaDate: 2009-09-26 13:51:12
Subject: Re: DataSource.setMaxConnections() - Does not work

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