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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-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

Browse pgsql-bugs by date

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

Browse pgsql-jdbc by date

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