Re: AbstractJdbc2Array - another patch - Mailing list pgsql-jdbc
From | Eric Lenio |
---|---|
Subject | Re: AbstractJdbc2Array - another patch |
Date | |
Msg-id | 20071122060905.GB25875@lenio.net Whole thread Raw |
In response to | Re: AbstractJdbc2Array - another patch (Kris Jurka <books@ejurka.com>) |
Responses |
Re: AbstractJdbc2Array - another patch
Re: AbstractJdbc2Array - another patch |
List | pgsql-jdbc |
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.
Attachment
pgsql-jdbc by date: