Обсуждение: JDBC-Interface - Behaviour on Update, Insert or Delete returning ResultSets - Inconsistency to Console & ODBC

Dear Ladies and Gentlemen,

I do not know if this can even be considered a bug, but I would be
pleased, if somebody could make a statement on this:

environment:


  PostgreSQL 8.1 and 8.2
  Redhat and WinXP

While using views calling functions on INSERT, UPDATE and DELETE via
according rules, I noticed an inconsistent behaviour of the
JDBC-interface of postgres;
 an INSERT-, UPDATE- or DELETE-statement producing tuples as
return-value (in our case through rules calling functions but although
via the 'RETURNING'-clause of a single INSERT- or UPDATE-statement) is
returning the expected number of tuples when called via the console
(even through pgAdmin) or via ODBC
BUT
when called via JDBC only an 'UpdateCount' of 0 is returned;
debugging to protocol-level showed, that the postgreSQL-server does not
even differ between a 'simple' UPDATE or one returning tuples;

a 'simple' UPDATE returning only an 'UpdateCount' produces the
following sequence of commands (at protocol-level):
49 - 50 - 110 - 67 - 90      or in characters      '1' - '2' - 'n' -
'C' - Z'
exactly the same is returned on an UPDATE returning tuples;
of course, as 'n' means that no data is available (according to class
org.postgresql.core.v3.QueryExecutorImpl) no tuple will be available
and the 'UpdateCount' will also be 0;

... so am I right guessing that there is no way to retrieve the
resulting tuples via JDBC? (- in difference to the console and ODBC)

For our needs we implemented a java.sql.Driver encapsulating the
sun.jdbc.odbc.JdbcOdbcDriver that returns the expected values as a
workaround, but that causes additional conversions that are not really
necessary;
in my opinion it would be a better solution to leave the decision,
whether to return the tuples, an 'UpdateCount' or even throw an
Exception up to the implementor of the driver and not to ignore the
fact that tuples where produced already on server-side;

I am looking forward to hearing your point of view!

With best regards,

Otto Weichselbaum


--

<!--
body{
font-family: arial;
font-size: 12px;
}

p.title{
font-size: 14px;
font-variant: small-caps;
font-weight: bold;
font-style: italic;
margin-top: 3px;
margin-bottom: 3px;
}

p.space{
margin-top: 2px;
margin-bottom: 2px;
}
 -->

____________________________
SEW – Otto Weichselbaum
DI (FH) Otto Weichselbaum
A-4040 LINZ, Heindlstrasse 19/4
eMail: Otto.Weichselbaum@sew.at
fax: +43 (0) 732 925400
mobile: +43 (0) 664 8251111

On Sat, 18 Aug 2007, Otto Weichselbaum wrote:

> While using views calling functions on INSERT, UPDATE and DELETE via
> according rules, I noticed an inconsistent behaviour of the
> JDBC-interface of postgres;
> =A0an INSERT-, UPDATE- or DELETE-statement producing tuples as return-val=
ue
> (in our case through rules calling functions but although via the
> 'RETURNING'-clause of a single INSERT- or UPDATE-statement) is returning
> the expected number of tuples when called via the console (even through
> pgAdmin) or via ODBC
> BUT
> when called via JDBC only an 'UpdateCount' of 0 is returned;
> debugging to protocol-level showed, that the postgreSQL-server does not
> even differ between a 'simple' UPDATE or one returning tuples;

I believe this differing results you are seeing is based upon whether the=
=20
query is executed using the simple or extended query protocol.  The JDBC=20
driver always uses extended query protocol when speaking to a V3 protocol=
=20
capable server.  Another workaround you can use is adding=20
?protocolVersion=3D2 to your URL to make it use the V2 protocol and simple=
=20
query execution.

It works with the simple query protocol because you send the server a=20
query and then loop retrieving any number of results that are returned.=20
The extended query protocol is designed around single query gives a=20
single result, so it isn't really prepared to handle the update count=20
and results at the same time.

Kris Jurka