Re: AbstractJdbc2Array - another patch

[Eric Lenio <eric(at)lenio(dot)net>]

On Wed, Nov 21, 2007 at 05:49:28PM -0500, Kris Jurka wrote:
> 
> 
> On Tue, 30 Oct 2007, Marek Lewczuk wrote:
> 
> >in the attachment you can find jdbc.patch (that includes patches for a few 
> >classes). You will see that I've added base types array types and right 
> >now Array implementation works as should (your last test case is working, 
> >which means that when using Array.getResultSet() returns appropriate 
> >Array.getBaseType() and Array.getBaseTypeName()). However those changes 
> >are not enough, there has to be more to be done in order to provide 
> >support for user defined types, but  I think that should be done later. I 
> >also think that class TypeInfoCache must be absolutely rewritten, cause it 
> >is not prepared for user defined types.
> >
> 
> Attached is a revised version of your patch after I worked on it a bit. 
> Things I've changed:
> 
> 1) Looking up the array type for a base type by using typelem doesn't work 
> because typelem is not unique.  Since no code was calling getPGTypeArray, 
> I just removed this code.
> 
> 2) Fixed driver code that was relying on the array return type in 
> AbstractJdbc2DatabaseMetaData.
> 
> 3) Fixed the regression tests and added new ones to verify that array 
> handling works.
> 
> 4) Changed Array.getResultSet to use generic coding rather than hardcoding 
> type oids for each java.sql.Types value.  This allows getResultSet to be 
> used on types that aren't known to the driver, like aclitem[].  You still 
> can't call getArray on this type, but we're getting closer.
> 
> 5) Array.getResultSet didn't respect index or offset parameters.
> 
> 6) For TypeInfoCache I've added a new column to link the base and array 
> types instead of duplicating the whole rows.
> 
> 7) Code did not correctly handle a string value of NULL in arrays for 8.1 
> and earlier server versions.
> 
> So with these changes, I think the code is pretty much ready to go, with 
> the exception of how multidimensional results are returned.  The way you 
> wrap the arrays in Object[] makes it impossible to cast to things like 
> Integer[][].  Also I think we should be able to return multidimensional 
> arrays of primitive type if the "compatible" option is set to 8.2.  I 
> think you should be using java.lang.reflect.Array#newInstance to create 
> the arrays you are returning to get the correct type instead of building 
> them up incrementally.
> 
> Kris Jurka

Kris/Marek: I've attached a very small followup patch which addresses a
need I had: I was using java.sql.DatabaseMetaData's getColumns method to
attempt to get the COLUMN_SIZE attribute for a column of type "character
varying(255) []".  Without my patch (applied after Kris's patches) the
COLUMN_SIZE would be 2147483647, with the patch it would be 255.  I am
by no means a JDBC or Postgresql expert, so maybe I am way off base.
What do you think?

Eric.

--- org/postgresql/jdbc2/TypeInfoCache.java	2007-11-22 00:49:24.000000000 -0500
+++ org/postgresql/jdbc2/TypeInfoCache.java.new	2007-11-22 00:49:18.000000000 -0500
@@ -491,6 +491,7 @@
             case Oid.INTERVAL:
                 return 49; // SELECT LENGTH('-123456789 years 11 months 33 days 23 hours 10.123456 seconds'::interval);
             case Oid.VARCHAR:
+            case Oid.VARCHAR_ARRAY:
             case Oid.BPCHAR:
                 if (typmod == -1)
                     return Integer.MAX_VALUE;