Re: Batch INSERT failing with error 22P02

[Eric Faulhaber <ecf(at)goldencode(dot)com>]

Eric Faulhaber wrote:
> Kris Jurka wrote:
> > 2) Where's the unspecified type coming from?  I've put in a hack to 
> > the driver to throw an exception when the first unspecified type is 
> > set which should hopefully provide enough information to track it 
> > back to your application.  Unspecified types are perfectly legal, so 
> > this isn't a real problem, but it may be informational.
>
> I turned on some additional logging in our code to see what data is 
> being bound to each parameter in our UserType implementation.  It 
> seems the unspecified type is coming from a Date object bound with 
> PreparedStatement.setDate(int, java.sql.Date).  At least, this is the 
> first parameter that triggers the test.

How relevant is the following change to this mystery?  This is an 
excerpt from a diff of AbstractJdbc2Statement between the versions we've 
been discussing, specifically, the internals of the setDate(int, Date, 
Calendar) method:

--- 
postgresql-jdbc-8.1-408.src/org/postgresql/jdbc2/AbstractJdbc2Statement.java        
2006-11-05 00:44:44.000000000 -0500
+++ 
postgresql-jdbc-8.2-506.src/org/postgresql/jdbc2/AbstractJdbc2Statement.java        
2007-07-27 05:01:53.000000000 -0400

...

@@ -2897,7 +2919,7 @@
       if (cal != null)
           cal = (Calendar)cal.clone();

-        // We must use INVALID here, or inserting a Date-with-timezone 
into a
+        // We must use UNSPECIFIED here, or inserting a 
Date-with-timezone into a
       // timestamptz field does an unexpected rotation by the server's 
TimeZone:
       //
       // We want to interpret 2005/01/01 with calendar +0100 as
@@ -2916,7 +2938,7 @@
       //  2005-01-01 00:00:00+03
       // (1 row)

-        bindString(i, connection.getTimestampUtils().toString(cal, d), 
Oid.INVALID);
+        bindString(i, connection.getTimestampUtils().toString(cal, d), 
Oid.UNSPECIFIED);
   }

   public void setTime(int i, Time t, java.util.Calendar cal) throws 
SQLException
...

I mean, it obviously explains where the unspecified type is coming from, 
but how likely is that to trigger the FE/BE type mismatch we're seeing 
many records later?

Thanks,
Eric Faulhaber