Skip site navigation (1) Skip section navigation (2)

Re: PreparedStatement

From: Kris Jurka <books(at)ejurka(dot)com>
To: Nathan Crause <ncrause(at)uniclear(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: PreparedStatement
Date: 2004-09-26 19:40:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

On Sat, 25 Sep 2004, Nathan Crause wrote:

> Surely the use of CURRVAL in general would be useless in your example
> when using a SELECT in conjunction with the INSERT? Not only that,
> considering that you cannot guarantee the ORDER in which the SELECT will
> be returning records, I don't see how ANY autogenerated key result set
> would be meaningful, regardless of database engine (unless issuing a
> ORDER BY clause in the select).

Right, this is more a problem I have with the spec.  It just says it 
returns a ResultSet, but it doesn't tell us anything about what it 
contains or how it should work for multiple rows.

> I do agree with your ascertion that when writing a library all sorts of
> bazaar situations need to be taken into account - that's why I asked the
> question I did on my original post. That said, you are contending that no
> development at all is better than something that may solve at least some
> situations. If that is the case, then I dare say that when Postgres was
> at version 7.2, 90% of the DatabaseMetaData implementation for the JDBC
> needed to be scrapped, because it returned absolute bollocks (I haven't
> tried with the more recent releases).

The DatabaseMetaData got a significant upgrade for the 7.3 release.  Right 
now the problems I'm aware of are that it always returns JDBC2 results 
even though JDBC3 has added some more columns to some results and 
getTypeInfo doesn't sort correctly.  If you've noticed other problems 
please complain about them.

Regarding your original post, I was perhaps too harsh.  I don't mean to 
discourge you, I just wanted to make sure you knew what you were up 
against.  I don't have a problem with a partial implementation as long as 
that implementation does not return incorrect results for a situation it 
cannot handle.  If it errors out then, that's fine, I just suspect it will 
be difficult to detect these cases.

Kris Jurka

In response to


pgsql-jdbc by date

Next:From: Kris JurkaDate: 2004-09-28 10:40:53
Subject: Re: PreparedStatement
Previous:From: Kris JurkaDate: 2004-09-25 19:36:31
Subject: Re: Arrays Question? -Simon Moses

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group