I have run CTS 1.3.1 against CVS HEAD.
Here what I get:
+--------------------------------------------+
| | appclient | ejb | jsp | servlet |
|--------+-----------+------+------+---------|
| PASSED | 810 | 810 | 810 | 810 |
|--------+-----------+------+------+---------|
| FAILED | 387 | 387 | 407 | 407 |
|--------+-----------+------+------+---------|
| TOTAL | 1197 | 1197 | 1217 | 1217 |
+--------------------------------------------+
You can find the complete list of failing tests on this page:
http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/report.html
Links to stack traces are broken. If you care to see the whole thing,
grab this file:
http://people.redhat.com/vadimn/scratch/pgsql-jdbc/logs/2004-11-24/cvs-head.tar.gz
In CTS 1.2.1, each individual test attempts to drop and recreate the
tables it needs. This mode of operation leads to massive failures in
the EJB vehicle, as explained in
http://archives.postgresql.org/pgsql-jdbc/2004-11/msg00119.php
In CTS 1.3.1, all the necessary DDL is run prior to and separately
from the actual tests. See
http://java.sun.com/products/jdbc/jdbctestsuite-1_3_1.html
and grep for "initdb".
CTS 1.3.1 comes with two DDL files: one for Cloudscape and another one
for Oracle. I used the Cloudscape file and had to make the following
substitutions to make the "initdb" script succeeed when run against
PosgtreSQL:
TINYINT --> SMALLINT
LONGINT --> BIGINT
LONG VARCHAR --> TEXT
Long varbinary --> BYTEA
One problem that is common to both CTS 1.2.1 and CTS 1.3.1 is the
current backend's inability to support denormal floating point values.
As I mentioned in
http://archives.postgresql.org/pgsql-jdbc/2004-11/msg00137.php
the following currently fails
| DB1=> create table Real_Tab (MAX_VAL REAL, MIN_VAL REAL,NULL_VAL REAL);
| CREATE TABLE
| DB1=> insert into Real_Tab values(3.4E38,1.4E-45, null);
| ERROR: Bad float4 input format -- underflow
The magic numbers 3.4E38 and 1.4E-45 are java.lang.Float.MAX_FALUE and
java.lang.Float.MIN_VALUE. The backend currently only supports a
narrower (normalized) range:
http://www.postgresql.org/docs/7.4/interactive/datatype.html#DATATYPE-FLOAT
On most platforms, the real type has a range of at least 1E-37 to
1E+37 with a precision of at least 6 decimal digits.
To avoid getting gratuitous "float4 underflow" errors, I also made the
following change:
REAL --> DOUBLE PRECISION
Questions:
Do these numbers look about right?
Should I be using $CTS_HOME/bin/ctssql.ddl.cloudscape or
$CTS_HOME/bin/ctssql.ddl.oracle?
Dave, do you have a script for converting Oracle procedure
definitions into Postgres function definitions?
Thanks,
Vadim
