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

Re: 1+1+16 = 18 failures

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Vadim Nasardinov <vadimn(at)redhat(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: 1+1+16 = 18 failures
Date: 2004-11-18 18:58:00
Message-ID: 419CF0B8.1000206@fastcrypt.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
I've sort of eluded to this before. testSupportsStoredProcedures is 
allowed to return false.
The test suite is quite arbitrary, I'd sooner see your (and others) 
efforts going towards beefing up our internal test suite.

Dave

Vadim Nasardinov wrote:

>On Wednesday 17 November 2004 15:25, Oliver Jowett wrote:
>  
>
>>Did you get any useful test results from the non-EJB modes? Anything
>>the driver does wrong there?
>>    
>>
>
>No, I didn't see any cases where the blame could be pegged squarely on
>the driver, except the testSupportsStoredProcedures test.
>
>If I run the test with this exclusion list:
>http://java.sun.com/products/jdbc/exclude.1.2.1.txt?button=Download
>
>I get 18 failures out of 548 tests.  One of them is
>
>  testSupportsStoredProcedures
>
>This fails because in
>org/postgresql/jdbc2/AbstractJdbc2DatabaseMetaData.java, we have
>
>     public boolean supportsStoredProcedures() throws SQLException
>     {
>         return false;
>     }
>
>whereas the test harness expects this method to return true.
>
>One other failure looks like a bug in the harness.  Specifically,
>   testGetSQLState
>fails because this condition
>  b.getSQLState() instanceof java.lang.String
>
>tests false, where b is a SQLException.  Now, the only way this can
>possibly happen is if getSQLState() returns null.  Looking at the
>javadoc
>http://java.sun.com/j2se/1.4.2/docs/api/java/sql/SQLException.html#getSQLState%28%29
>
>I don't see anything that says the method is not allowed to return
>null.  Looks like a bug in the CTS.
>
>
>The remaining 16 failures are all due to the same reason.  The backend
>chokes on the following query (or some variation thereof):
>
>  | DB1=> select substring(version(), 1, 20) as version;
>  |        version        
>  | ----------------------
>  |  PostgreSQL 7.3.4-RH 
>  | (1 row)
>  | 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 funny part is that I can do
>
>  | DB1=> select 1.4E-45;
>  |                      ?column?                     
>  | --------------------------------------------------
>  |  0.0000000000000000000000000000000000000000000014
>  | (1 row)
>  | DB1=> select 3.4E38;
>  |                 ?column?                 
>  | -----------------------------------------
>  |  340000000000000000000000000000000000000
>  | (1 row)
>
>But I would have to test this against a more recent version of the
>backend.  In any case, these 16 failures don't be seem to be caused
>by the driver.
>
>
>
>Vadim
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>               http://archives.postgresql.org
>
>
>  
>

-- 
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

In response to

pgsql-jdbc by date

Next:From: Vadim NasardinovDate: 2004-11-18 21:19:50
Subject: test coverage (was: Re: JDBC CTS 1.2.1)
Previous:From: Vadim NasardinovDate: 2004-11-18 18:20:32
Subject: 1+1+16 = 18 failures (was: Re: JDBC CTS 1.2.1)

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