pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedJDBC next() method
13+ messages / 5 participants
[nested] [flat]
* JDBC next() method
@ 1999-04-14 12:57 Jon Barnett <jbarnett@pobox.com>
0 siblings, 1 reply; 13+ messages in thread
From: Jon Barnett @ 1999-04-14 12:57 UTC (permalink / raw)
To: 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
I'm not quite sure about the correct operation of the JDBC next() method.
Suppose I have the following code:
queryResult = dbStatement.executeQuery("select max(history_id) from history");
if (queryResult.next())
nextID = queryResult.getLong(1) + 1;
else
nextID = 0;
With the postgresql JDBC driver, the minimum value for nextID is 1, even if the
history table is empty. I had expected that an empty result set would be
returned if the history table is empty (0 rows returned for the select), and
queryResult.next() would be false. Is this an incorrect interpretation on my
part?
Thanks,
JonB.
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-14 13:18 Peter Mount <petermount@it.maidstone.gov.uk>
0 siblings, 0 replies; 13+ messages in thread
From: Peter Mount @ 1999-04-14 13:18 UTC (permalink / raw)
To: jbarnett@pobox.com, "'pgsql-interfaces@hub.org'" <pgsql-interfaces@hub.org>
This looks ok.
queryResult is null if there was an error in the query, so you should
check for that.
However, normal use would have the result parsed within a
while(queryResult.next()) {} loop, so your interpretation is correct.
Peter
--
Peter T Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as the
official words of Maidstone Borough Council
-----Original Message-----
From: Jon Barnett [mailto:jbarnett@pobox.com]
Sent: Wednesday, April 14, 1999 1:57 PM
To: 'pgsql-interfaces@hub.org'
Subject: [INTERFACES] JDBC next() method
I'm not quite sure about the correct operation of the JDBC next()
method.
Suppose I have the following code:
queryResult = dbStatement.executeQuery("select max(history_id) from
history");
if (queryResult.next())
nextID = queryResult.getLong(1) + 1;
else
nextID = 0;
With the postgresql JDBC driver, the minimum value for nextID is 1, even
if the
history table is empty. I had expected that an empty result set would
be
returned if the history table is empty (0 rows returned for the select),
and
queryResult.next() would be false. Is this an incorrect interpretation
on my
part?
Thanks,
JonB.
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-14 14:37 Jon Barnett <jbarnett@pobox.com>
0 siblings, 0 replies; 13+ messages in thread
From: Jon Barnett @ 1999-04-14 14:37 UTC (permalink / raw)
To: 'Peter Mount' <petermount@it.maidstone.gov.uk>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
On Wednesday, 14 April 1999 23:18, Peter Mount
[SMTP:petermount@it.maidstone.gov.uk] wrote:
> This looks ok.
>
> queryResult is null if there was an error in the query, so you should
> check for that.
>
> However, normal use would have the result parsed within a
> while(queryResult.next()) {} loop, so your interpretation is correct.
I don't think the query should give an error - as the query is at least
syntactically correct. Certainly, if I check for a queryResult == null, the
condition doesn't occur for an empty table.
I just had a quick browse on some old JDBC notes and it looks like the correct
solution is:
queryResult = dbStatement.executeQuery("select max(history_id) from history");
queryResult.next();
nextID = queryResult.getLong(1) + 1;
if (queryResult.wasNull())
nextID = 0;
Note: queryResult.wasNull() only works immediately after calling a getxxx
method.
Thanks.
JonB.
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-14 14:51 Peter Mount <petermount@it.maidstone.gov.uk>
0 siblings, 0 replies; 13+ messages in thread
From: Peter Mount @ 1999-04-14 14:51 UTC (permalink / raw)
To: jbarnett@pobox.com, "'Peter Mount'" <petermount@it.maidstone.gov.uk>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
That's correct (we use that syntax in the driver's source ourselves).
wasNull() is only valid after a getxxx() call, but only for the last
call.
Peter
--
Peter T Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as the
official words of Maidstone Borough Council
-----Original Message-----
From: Jon Barnett [mailto:jbarnett@pobox.com]
Sent: Wednesday, April 14, 1999 3:37 PM
To: 'Peter Mount'; 'pgsql-interfaces@hub.org'
Subject: RE: [INTERFACES] JDBC next() method
On Wednesday, 14 April 1999 23:18, Peter Mount
[SMTP:petermount@it.maidstone.gov.uk] wrote:
> This looks ok.
>
> queryResult is null if there was an error in the query, so you should
> check for that.
>
> However, normal use would have the result parsed within a
> while(queryResult.next()) {} loop, so your interpretation is correct.
I don't think the query should give an error - as the query is at least
syntactically correct. Certainly, if I check for a queryResult == null,
the
condition doesn't occur for an empty table.
I just had a quick browse on some old JDBC notes and it looks like the
correct
solution is:
queryResult = dbStatement.executeQuery("select max(history_id) from
history");
queryResult.next();
nextID = queryResult.getLong(1) + 1;
if (queryResult.wasNull())
nextID = 0;
Note: queryResult.wasNull() only works immediately after calling a
getxxx
method.
Thanks.
JonB.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: [INTERFACES] JDBC next() method
@ 1999-04-19 15:34 Herouth Maoz <herouth@oumail.openu.ac.il>
parent: Jon Barnett <jbarnett@pobox.com>
0 siblings, 0 replies; 13+ messages in thread
From: Herouth Maoz @ 1999-04-19 15:34 UTC (permalink / raw)
To: jbarnett@pobox.com <jbarnett@pobox.com>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
At 15:57 +0300 on 14/04/1999, Jon Barnett wrote:
> I had expected that an empty result set would be
> returned if the history table is empty (0 rows returned for the select), and
> queryResult.next() would be false. Is this an incorrect interpretation
>on my
> part?
It is. In PostgreSQL, when an aggregate function is used, it always returns
one row containing one field. If it had no values that matched the query,
that one field is NULL.
The result of an aggregate is never 0 rows. It is always one row (per group
if you used GROUP BY).
This is the reason why you have to check for a null field rather than for
the result of next(). You have to call next(), but you don't really have to
check its value, because it will be true once (and once only). You call it
merely to fetch the row. And then you get the value of the field thus
retrieved, and check it for null.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-23 15:26 Jon Barnett <jbarnett@pobox.com>
0 siblings, 1 reply; 13+ messages in thread
From: Jon Barnett @ 1999-04-23 15:26 UTC (permalink / raw)
To: 'Herouth Maoz' <herouth@oumail.openu.ac.il>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
On Tuesday, 20 April 1999 1:35, Herouth Maoz [SMTP:herouth@oumail.openu.ac.il]
wrote:
> At 15:57 +0300 on 14/04/1999, Jon Barnett wrote:
>
>
> > I had expected that an empty result set would be
> > returned if the history table is empty (0 rows returned for the select),
> > and
> > queryResult.next() would be false. Is this an incorrect interpretation
> >on my
> > part?
>
> It is. In PostgreSQL, when an aggregate function is used, it always returns
> one row containing one field. If it had no values that matched the query,
> that one field is NULL.
The question is less one of "what is required to correctly interpret the result
from the postgresql jdbc driver" and more a case of determining whether this
result conforms to the jdbc api definitions. To re-phrase this; if I employed
a different JDBC driver, would I obtain the same result? For after all, the
goal of the JDBC layer is to provide a consistent interface, independent of the
database to which you are connecting, particularly when you can late bind the
driver (specify the driver you want to use at run-time).
Best regards,
Jon.
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-23 20:45 herouth maoz <herouth@oumail.openu.ac.il>
parent: Jon Barnett <jbarnett@pobox.com>
0 siblings, 0 replies; 13+ messages in thread
From: herouth maoz @ 1999-04-23 20:45 UTC (permalink / raw)
To: Jon Barnett <jbarnett@pobox.com>; +Cc: 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
On Sat, 24 Apr 1999, Jon Barnett wrote:
> The question is less one of "what is required to correctly interpret the result
> from the postgresql jdbc driver" and more a case of determining whether this
> result conforms to the jdbc api definitions.To re-phrase this; if I employed
> a different JDBC driver, would I obtain the same result? For after all, the
> goal of the JDBC layer is to provide a consistent interface, independent of the
> database to which you are connecting, particularly when you can late bind the
> driver (specify the driver you want to use at run-time).
The question here is not on the JDBC level. As far as JDBC is concerned,
the behaviour of the posgresql JDBC driver is conformant: In case no rows
are returned, next() will return false upon first call. In case a row is
returned, which contains a null value, next() will return true, the value
of the field is 0, and you test it for null otherwise.
No, the question is whether Postgres's behaviour - of returning a row with
a null field in case no rows fell into the WHERE category - is compatible
with other databases, or indeed with the SQL standard. I don't have the
standard in front of me at this moment. But you must understand that this
is how PostgreSQL behaves, no matter whether your frontend is in Java,
python, perl or C. It's not a question of JDBC.
Herouth
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-24 00:45 Jon Barnett <jbarnett@pobox.com>
0 siblings, 1 reply; 13+ messages in thread
From: Jon Barnett @ 1999-04-24 00:45 UTC (permalink / raw)
To: 'herouth maoz' <herouth@oumail.openu.ac.il>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
On Saturday, 24 April 1999 6:45, herouth maoz [SMTP:herouth@oumail.openu.ac.il]
wrote:
> No, the question is whether Postgres's behaviour - of returning a row with
> a null field in case no rows fell into the WHERE category - is compatible
> with other databases, or indeed with the SQL standard. I don't have the
> standard in front of me at this moment. But you must understand that this
> is how PostgreSQL behaves, no matter whether your frontend is in Java,
> python, perl or C. It's not a question of JDBC.
I concede your point on that. I'm just obsessing over the ultimate result of
this quirk(?) - independence of the application.
From a practicalities point of view, if the result is not compliant with the
SQL standard, the question is whether to hide it in the abstraction layer (JDBC
driver) or fix it at the source - I guess costs and complexity of the fix will
determine that (although it is always better to fix it at the source). Of
course, hiding it in the abstraction layer means you need to do the same for
every interface (which is a headache for maintainers).
This is just speculation and musing, in any case, as I am not sure what the SQL
standard says with respect to this limit case (where a table is empty). More
research needed I suppose. :)
JonB.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: [INTERFACES] JDBC next() method
@ 1999-04-24 16:00 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jon Barnett <jbarnett@pobox.com>
0 siblings, 0 replies; 13+ messages in thread
From: Tom Lane @ 1999-04-24 16:00 UTC (permalink / raw)
To: jbarnett@pobox.com <jbarnett@pobox.com>; +Cc: 'herouth maoz' <herouth@oumail.openu.ac.il>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
Jon Barnett <jbarnett@pobox.com> writes:
> From a practicalities point of view, if the result is not compliant
> with the SQL standard, the question is whether to hide it in the
> abstraction layer (JDBC driver) or fix it at the source
If you can demonstrate that this behavior [NULL result from aggregate
functions] is not compliant with the SQL92 standard, then the Postgres
backend will get fixed.
There's been discussion of this point before on the hackers list,
with some people feeling that the current behavior is OK and others
not happy with it, but so far no one has made a convincing case about
what the standard expects.
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-25 12:58 Jon Barnett <jbarnett@pobox.com>
0 siblings, 1 reply; 13+ messages in thread
From: Jon Barnett @ 1999-04-25 12:58 UTC (permalink / raw)
To: 'Tom Lane' <tgl@sss.pgh.pa.us>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>; +Cc: 'herouth maoz' <herouth@oumail.openu.ac.il>
On Sunday, 25 April 1999 2:01, Tom Lane [SMTP:tgl@sss.pgh.pa.us] wrote:
> If you can demonstrate that this behavior [NULL result from aggregate
> functions] is not compliant with the SQL92 standard, then the Postgres
> backend will get fixed.
>
> There's been discussion of this point before on the hackers list,
> with some people feeling that the current behavior is OK and others
> not happy with it, but so far no one has made a convincing case about
> what the standard expects.
It seems that the standard is quite ambiguous as to what it expects and doesn't
address the limit case (what happens for an aggregate function result when a
table is empty). My SQL Programmer's Reference (ISBN 1-56604-760-9) has
nothing to say on this matter and I haven't successfully found a copy of the
SQL92 specifications (seems harder than tracking down a printed copy of
"Historia Regum Britanniae"). I suspect that the SQL specifications may also
overlook the issue as well. *sigh*
Upon reflection on possible scenarios, it seems that the aggregates should
return a row with a null value (but I'm not wholly certain on this). In SQL
the following is valid:
select column1, column2, column3
from table t
where column3 =
(select max(column3)
from table
where column2 = t.column2)
Should the nested select have no max value (being an empty result), then
perhaps a null is required to be returned such that the comparison for the
outer select may still be made. I had overlooked this possibility. With it
coming to light, it appears we should have no problems with the current
implementation as this example seems to indirectly point to a null value return
being a valid result. Someone may wish to check my logic on this.
My apologies for ever doubting that things were not working correctly. :)
Best regards,
JonB.
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: [INTERFACES] JDBC next() method
@ 1999-04-25 14:25 Herouth Maoz <herouth@oumail.openu.ac.il>
parent: Jon Barnett <jbarnett@pobox.com>
0 siblings, 2 replies; 13+ messages in thread
From: Herouth Maoz @ 1999-04-25 14:25 UTC (permalink / raw)
To: jbarnett@pobox.com <jbarnett@pobox.com>; 'Tom Lane' <tgl@sss.pgh.pa.us>; 'pgsql-interfaces@hub.org' <pgsql-interfaces@hub.org>
At 15:58 +0300 on 25/04/1999, Jon Barnett wrote:
> It seems that the standard is quite ambiguous as to what it expects and
>doesn't
> address the limit case (what happens for an aggregate function result when a
> table is empty). My SQL Programmer's Reference (ISBN 1-56604-760-9) has
> nothing to say on this matter and I haven't successfully found a copy of the
> SQL92 specifications (seems harder than tracking down a printed copy of
> "Historia Regum Britanniae"). I suspect that the SQL specifications may
>also
> overlook the issue as well. *sigh*
Ah, well, I have a (late draft) of the SQL92 standard. And here is what it
has to say on the matter (note 2-b-i):
<<< begin quotation from standard >>>
General Rules
1) Case:
a) If COUNT(*) is specified, then the result is the cardinality
of T.
b) Otherwise, let TX be the single-column table that is the
result of applying the <value expression> to each row of T
and eliminating null values. If one or more null values are
eliminated, then a completion condition is raised: warning-
null value eliminated in set function.
2) If DISTINCT is specified, then let TXA be the result of elimi-
nating redundant duplicate values from TX. Otherwise, let TXA be
TX.
Case:
a) If the <general set function> COUNT is specified, then the
result is the cardinality of TXA.
b) If AVG, MAX, MIN, or SUM is specified, then
Case:
i) If TXA is empty, then the result is the null value.
ii) If AVG is specified, then the result is the average of the
values in TXA.
iii) If MAX or MIN is specified, then the result is respec-
tively the maximum or minimum value in TXA. These results
are determined using the comparison rules specified in
Subclause 8.2, "<comparison predicate>".
iv) If SUM is specified, then the result is the sum of the
values in TXA. If the sum is not within the range of the
data type of the result, then an exception condition is
raised: data exception-numeric value out of range.
<<< end quotation from standard >>>
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: [INTERFACES] JDBC next() method
@ 1999-04-25 16:40 Tom Lane <tgl@sss.pgh.pa.us>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 0 replies; 13+ messages in thread
From: Tom Lane @ 1999-04-25 16:40 UTC (permalink / raw)
To: Herouth Maoz <herouth@oumail.openu.ac.il>; +Cc: pgsql-interfaces@hub.org
Herouth Maoz <herouth@oumail.openu.ac.il> writes:
> Ah, well, I have a (late draft) of the SQL92 standard. And here is what it
> has to say on the matter (note 2-b-i):
> Case:
> a) If the <general set function> COUNT is specified, then the
> result is the cardinality of TXA.
> [ie, 0 for an empty set - tgl]
> b) If AVG, MAX, MIN, or SUM is specified, then
> Case:
> i) If TXA is empty, then the result is the null value.
Well, this is certainly adequate precedent for the behavior of these
particular aggregates --- although I'd have to say that the standard-
writers blew it for SUM; SUM of an empty set ought to return 0 not
null. (It looks like Postgres follows the spec, however.)
Anyway, we have here precedent for deciding on a function-by-function
basis whether an aggregate over an empty selection should return NULL
or return an appropriate ordinary value. There's no case in which the
result of the aggregate has no rows, however. So I think Postgres
is fairly standards-compliant on this point.
Now that I think about it, the arguments on the hackers list were not
about the plain SELECT case but about the GROUP BY case. For example,
if you do
SELECT productname, AVG(saleprice) FROM sales GROUP BY productname;
then you get a row in the output for each different productname, and
a separate instance of AVG is run over the prices for each group.
(Unless there are NULLs in the saleprice column, none of the AVG
instances could ever return a null result.)
BUT: what happens if the sales table is empty? There are no
productnames, therefore no groups, therefore no rows ought to appear
in the output (IMHO). However, what Postgres actually does right now
is to emit one all-nulls row (but only if an aggregate function was
used; if you say "SELECT productname FROM sales GROUP BY productname"
then you get no rows). That is the behavior that we've gone 'round and
'round on without any resolution; it seems obviously inconsistent to me,
but others think it's OK because it parallels what happens in the non-
GROUP BY case.
Is there anything in the SQL92 spec addressing this point?
regards, tom lane
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: [INTERFACES] JDBC next() method
@ 1999-04-25 17:27 Herouth Maoz <herouth@oumail.openu.ac.il>
parent: Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 0 replies; 13+ messages in thread
From: Herouth Maoz @ 1999-04-25 17:27 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces
At 19:40 +0300 on 25/04/1999, Tom Lane wrote:
> Well, this is certainly adequate precedent for the behavior of these
> particular aggregates --- although I'd have to say that the standard-
> writers blew it for SUM; SUM of an empty set ought to return 0 not
> null. (It looks like Postgres follows the spec, however.)
I don't agree. Suppose you want to sum of all your banking transactions in
January. There is a distinction between getting a 0, meaning you had a
balanced budget in January, and getting a null, meaning you made no
transactions in January.
> Now that I think about it, the arguments on the hackers list were not
> about the plain SELECT case but about the GROUP BY case. For example,
> if you do
>
> SELECT productname, AVG(saleprice) FROM sales GROUP BY productname;
>
> then you get a row in the output for each different productname, and
> a separate instance of AVG is run over the prices for each group.
> (Unless there are NULLs in the saleprice column, none of the AVG
> instances could ever return a null result.)
>
> BUT: what happens if the sales table is empty? There are no
> productnames, therefore no groups, therefore no rows ought to appear
> in the output (IMHO). However, what Postgres actually does right now
> is to emit one all-nulls row (but only if an aggregate function was
> used; if you say "SELECT productname FROM sales GROUP BY productname"
> then you get no rows). That is the behavior that we've gone 'round and
> 'round on without any resolution; it seems obviously inconsistent to me,
> but others think it's OK because it parallels what happens in the non-
> GROUP BY case.
>
> Is there anything in the SQL92 spec addressing this point?
Ooh, definitely... Here are the general rules regarding a query expression
(i.e. a general select statement). A grouped table is defined somewhere
else in the document as the result of a group by or having clause. You
really should read the definitions (I can make my draft available on the
web for a while. I don't remember where I downloaded it).
<<< Begin quotation >>>
General Rules
1) Case:
a) If T is not a grouped table, then
Case:
i) If the <select list> contains a <set function specifica-
tion> that contains a reference to a column of T or di-
rectly contains a <set function specification> that does
not contain an outer reference, then T is the argument or
argument source of each such <set function specification>
and the result of the <query specification> is a table con-
sisting of 1 row. The i-th value of the row is the value
specified by the i-th <value expression>.
ii) If the <select list> does not include a <set function spec-
ification> that contains a reference to T, then each <value
expression> is applied to each row of T yielding a table of
M rows, where M is the cardinality of T. The i-th column of
the table contains the values derived by the evaluation of
the i-th <value expression>.
Case:
1) If the <set quantifier> DISTINCT is not specified, then
the table is the result of the <query specification>.
2) If the <set quantifier> DISTINCT is specified, then the
result of the <query specification> is the table derived
from that table by the elimination of any redundant
duplicate rows.
b) If T is a grouped table, then
Case:
i) If T has 0 groups, then the result of the <query specifica-
tion> is an empty table.
ii) If T has one or more groups, then each <value expression>
is applied to each group of T yielding a table of M rows,
where M is the number of groups in T. The i-th column of
the table contains the values derived by the evaluation of
the i-th <value expression>. When a <value expression> is
applied to a given group of T, that group is the argument
or argument source of each <set function specification> in
the <value expression>.
Case:
1) If the <set quantifier> DISTINCT is not specified, then
the table is the result of the <query specification>.
2) If the <set quantifier> DISTINCT is specified, then the
result of the <query specification> is the table derived
from T by the elimination of any redundant duplicate
rows.
<<< End quotation >>>
Which implies exactly what you say. Perhaps you should forward this to the
Hackers list to re-start the argument - I am not a subscriber there.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~1999-04-25 17:27 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-04-14 12:57 JDBC next() method Jon Barnett <jbarnett@pobox.com>
1999-04-19 15:34 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1999-04-14 13:18 RE: [INTERFACES] JDBC next() method Peter Mount <petermount@it.maidstone.gov.uk>
1999-04-14 14:37 RE: [INTERFACES] JDBC next() method Jon Barnett <jbarnett@pobox.com>
1999-04-14 14:51 RE: [INTERFACES] JDBC next() method Peter Mount <petermount@it.maidstone.gov.uk>
1999-04-23 15:26 RE: [INTERFACES] JDBC next() method Jon Barnett <jbarnett@pobox.com>
1999-04-23 20:45 ` herouth maoz <herouth@oumail.openu.ac.il>
1999-04-24 00:45 RE: [INTERFACES] JDBC next() method Jon Barnett <jbarnett@pobox.com>
1999-04-24 16:00 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-04-25 12:58 RE: [INTERFACES] JDBC next() method Jon Barnett <jbarnett@pobox.com>
1999-04-25 14:25 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1999-04-25 16:40 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-04-25 17:27 ` Herouth Maoz <herouth@oumail.openu.ac.il>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox