CTS 1.3.1 results - Mailing list pgsql-jdbc

From Vadim Nasardinov
Subject CTS 1.3.1 results
Date
Msg-id 200411241537.31943@vadim.nasardinov
Whole thread Raw
Responses Re: CTS 1.3.1 results
Re: CTS 1.3.1 results
List pgsql-jdbc
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




pgsql-jdbc by date:

Previous
From: Tom Lane
Date:
Subject: Re: UNICODE and 8.0.0beta5
Next
From: "Roger Niederland"
Date:
Subject: query string on a prepared statement