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