7.1beta1 JDBC Nested cursor problem
I think that I've found a little bug in the 7.1beta1 JDBC drivers. Attached is a simple test case which produces the problem on my setup (LinuxPPC 2000, on Apple PowerMac G3-400Mhz, 512MB). It would seem that the drivers and/or the DBMS has a problem with nested queries, even simple ones.
Here's the stacktrace:
Bad Long
at org.postgresql.jdbc2.ResultSet.getLong(ResultSet.java:284)
at Test.go(Test.java:35)
at Test.main(Test.java:15)
I'm using the 7.0.2 JDBC drivers against the 7.1beta1 backend and
everything seems to be working fine with those, just the new ones (7.1beta1) have this problem.
Stu.
-- create table/data script
create table mytest (mykey int8, foo varchar(20));
insert into mytest(mykey,foo) values (0,'stuff');
insert into mytest(mykey,foo) values (1,'stuff');
insert into mytest(mykey,foo) values (2,'stuff');
insert into mytest(mykey,foo) values (3,'stuff');
insert into mytest(mykey,foo) values (4,'stuff');
insert into mytest(mykey,foo) values (5,'stuff');
insert into mytest(mykey,foo) values (6,'stuff');
insert into mytest(mykey,foo) values (7,'stuff');
insert into mytest(mykey,foo) values (8,'stuff');
insert into mytest(mykey,foo) values (9,'stuff');
-- Test Program
import java.sql.*;
import java.io.*;
public class Test
{
public static void main(String [] args)
{
if(args.length!=3) {
System.err.println("Usage: <URL> <UID> <PWD>");
System.exit(1);
}
Test app=new Test();
try {
app.go(args[0],args[1],args[2]);
}
catch(Exception e) {
System.err.println(e.getMessage());
e.printStackTrace();
}
}
private void go(String url,String uid,String pwd) throws Exception
{
Class.forName("org.postgresql.Driver");
Connection connection=DriverManager.getConnection(url,uid,pwd);
connection.setAutoCommit(false);
PreparedStatement s=connection.prepareStatement("select mykey from mytest");
ResultSet rs=s.executeQuery();
while(rs.next()) {
PreparedStatement s2=connection.prepareStatement("select * from mytest where mykey=?");
s2.setLong(1,rs.getLong(1));
ResultSet rs2=s2.executeQuery();
while(rs2.next()) {
System.out.println(rs2.getLong(1) + " " + rs2.getString(2));
}
rs2.close();
s.close();
}
rs.close();
s.close();
connection.commit();
connection.close();
}
}
--
Stu Coates
Chelmsford, England U.K.
ICQ:146628
http://www.stucoates.com/
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
Stu Coates wrote:
I think that I've found a little bug in the 7.1beta1
Hi,
everywhere I here about 7.1beta, but I can't find it anywhere.
Is there a packaged betarelease or are you all talkling about
a specific cvs snapshot ?
Is 7.1beta1 stable 'enough' for productional use ?
Can you simply exchange 7.0.3 with 7.1beta1 ?
TIA
--
Nabil Sayegh
ftp://ftp.postgresql.org/pub/dev ...
and no, not ready for productional use unless you are brave ... figure
beta 3 before that, usually, but no guarantees until its released ...
On Sun, 10 Dec 2000, Nabil Sayegh wrote:
Stu Coates wrote:
I think that I've found a little bug in the 7.1beta1
Hi,
everywhere I here about 7.1beta, but I can't find it anywhere.
Is there a packaged betarelease or are you all talkling about
a specific cvs snapshot ?Is 7.1beta1 stable 'enough' for productional use ?
Can you simply exchange 7.0.3 with 7.1beta1 ?TIA
--
Nabil Sayegh
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Quoting Stu Coates <stu_coates@mail.com>:
I think that I've found a little bug in the 7.1beta1 JDBC drivers.
Attached is a simple test case which produces the problem on my setup
(LinuxPPC 2000, on Apple PowerMac G3-400Mhz, 512MB). It would seem that
the drivers and/or the DBMS has a problem with nested queries, even
simple ones.Here's the stacktrace:
Bad Long
at org.postgresql.jdbc2.ResultSet.getLong(ResultSet.java:284)
at Test.go(Test.java:35)
at Test.main(Test.java:15)I'm using the 7.0.2 JDBC drivers against the 7.1beta1 backend and
everything seems to be working fine with those, just the new ones
(7.1beta1) have this problem.
Yes, I'm still tracing this one. I discovered it a few weeks ago while looking
at rewriting the standard queries in DatabaseMetaData, but the backend seems to
return not an Int/Long but the type name instead.
It's interesting to see that other code is getting the same problem.
Peter