BUG? res.next() == false, but psql finds tuples?

From: Palle Girgensohn <girgen(at)pingpong(dot)net>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: BUG? res.next() == false, but psql finds tuples?
Date: 2005-04-22 13:43:43
Message-ID: D05A33D3D62A6E1764DC8B8B@rambutan.pingpong.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Hi!

Here's something really odd. Is it a bug in the jdbc driver? 8.0.311:

String query = "select lang from participant where userid = ? and
course_id = ?";
PreparedStatement ps = con.prepareStatement(query);
ps.setString(1, userId);
ps.setInt(2, courseId);
ResultSet res = ps.executeQuery();

System.err.println("[1] "+ps);

boolean hasNext = res.next();
System.err.println("hasNext: "+hasNext);

if (hasNext) {
System.err.println("[2]");
language = res.getString(1);
System.err.println("language: "+language);
}
System.err.println("[3]");

In the java error log:

---
[1] select lang from participant where userid = mango and course_id = 38
hasNext: false
[3]
---

but with psql, there's no problem getting a value:

mango=> select lang from participant where userid = 'mango' and course_id =
38;
lang
------
sv
(1 row)

(Connected to same database as same user.)

What's up? Is there a problem with the (new) prepared statement stuff?

postgresql-8.0.2, postgresql-jdbc-8.0.311, FreeBSD 4.11, java 1.4.2.

/Palle

PS. Here's a tcpdump of the query, FWIW:

13:37:14.909230 localhost.3277 > localhost.postgresql: P
564113356:564113492(136) ack 897123100 win 57344 <nop,nop,timestamp
729334714 729334409> (DF)
0x0000 4500 00bc 5038 4000 4006 ec01 7f00 0001 E(dot)(dot)(dot)P8(at)(dot)@.......
0x0010 7f00 0001 0ccd 1538 219f afcc 3579 031c .......8!...5y..
0x0020 8018 e000 6474 0000 0101 080a 2b78 c3ba ....dt......+x..
0x0030 2b78 c289 5000 0000 5100 7365 6c65 6374 +x..P...Q.select
0x0040 206c 616e 6720 6672 6f6d 2070 6172 7469 .lang.from.parti
0x0050 6369 7061 6e74 2077 6865 7265 2075 7365 cipant.where.use
0x0060 7269 6420 3d20 2431 2061 6e64 2063 6f75 rid.=.$1.and.cou
0x0070 7273 655f 6964 203d 2024 3200 0002 0000 rse_id.=.$2.....
0x0080 0413 0000 0017 4200 0000 1f00 0000 0200 ......B.........
0x0090 0000 0000 0200 0000 056d 616e 676f 0000 .........mango..
0x00a0 0002 3338 0000 4400 0000 0650 0045 0000 ..38..D....P.E..
0x00b0 0009 0000 0000 0053 0000 0004 .......S....
13:37:14.916554 localhost.postgresql > localhost.3277: P 1:59(58) ack 136
win 57344<nop,nop,timestamp 729334715 729334714> (DF)
0x0000 4500 006e 5039 4000 4006 ec4e 7f00 0001 E(dot)(dot)nP9(at)(dot)@..N....
0x0010 7f00 0001 1538 0ccd 3579 031c 219f b054 .....8..5y..!..T
0x0020 8018 e000 4908 0000 0101 080a 2b78 c3bb ....I.......+x..
0x0030 2b78 c3ba 3100 0000 0432 0000 0004 5400 +x..1....2....T.
0x0040 0000 1d00 016c 616e 6700 0000 4821 0003 .....lang...H!..
0x0050 0000 0019 ffff ffff ffff 0000 4300 0000 ............C...
0x0060 0b53 454c 4543 5400 5a00 0000 0549 .SELECT.Z....I

And here's one from psql (that works fine, result = 'sv'):

15:16:40.179908 localhost.1973 > localhost.postgresql: P 82:159(77) ack 294
win 57344 <nop,nop,timestamp 729931235 729930768> (DF)
0x0000 4500 0081 f57e 4000 4006 46f6 7f00 0001 E(dot)(dot)(dot)(dot)~(at)(dot)@.F.....
0x0010 7f00 0001 07b5 1538 3c3c 839d 3a40 cc42 .......8<<..:@.B
0x0020 8018 e000 77ae 0000 0101 080a 2b81 dde3 ....w.......+...
0x0030 2b81 dc10 5100 0000 4c73 656c 6563 7420 +...Q...Lselect.
0x0040 6c61 6e67 2066 726f 6d20 7061 7274 6963 lang.from.partic
0x0050 6970 616e 7420 7768 6572 6520 7573 6572 ipant.where.user
0x0060 6964 203d 2027 6d61 6e67 6f27 2061 6e64 id.=.'mango'.and
0x0070 2063 6f75 7273 655f 6964 203d 2033 383b .course_id.=.38;
0x0080 00 .
15:16:40.183568 localhost.postgresql > localhost.1973: P 294:355(61) ack
159 win 57344 <nop,nop,timestamp 729931236 729931235> (DF)
0x0000 4500 0071 f580 4000 4006 4704 7f00 0001 E(dot)(dot)q(dot)(dot)(at)(dot)@.G.....
0x0010 7f00 0001 1538 07b5 3a40 cc42 3c3c 83ea .....8..:@.B<<..
0x0020 8018 e000 28fb 0000 0101 080a 2b81 dde4 ....(.......+...
0x0030 2b81 dde3 5400 0000 1d00 016c 616e 6700 +...T......lang.
0x0040 0000 4821 0003 0000 0019 ffff ffff ffff ..H!............
0x0050 0000 4400 0000 0c00 0100 0000 0273 7643 ..D..........svC
0x0060 0000 000b 5345 4c45 4354 005a 0000 0005 ....SELECT.Z....
0x0070 49 I

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Vadim Nasardinov 2005-04-22 13:56:17 representing (seconds + microseconds) as floats [was:Re: Interval support for Postgres]
Previous Message Dave Cramer 2005-04-22 13:38:51 Re: COPY support for PostgreSql JDBC v8.0