From: | Eric Lenio <eric(at)lenio(dot)net> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | Marek Lewczuk <newsy(at)lewczuk(dot)com>, pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: AbstractJdbc2Array - another patch |
Date: | 2007-11-22 06:09:06 |
Message-ID: | 20071122060905.GB25875@lenio.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
TypeInfoCache.patch | text/plain | 517 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2007-11-22 06:26:56 | Re: AbstractJdbc2Array - another patch |
Previous Message | Kris Jurka | 2007-11-21 23:09:49 | Re: ResultSetMetaData getColumnTypeName() |