| Lists: | pgsql-patches |
|---|
| From: | "Greg Zoller" <gzoller(at)hotmail(dot)com> |
|---|---|
| To: | barry(at)xythos(dot)com |
| Cc: | pgman(at)candle(dot)pha(dot)pa(dot)us, rpijlman(at)wanadoo(dot)nl, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: JDBC Array Support, Take 2 |
| Date: | 2001-08-13 16:35:33 |
| Message-ID: | F8BQ8douFAeqJBKGMui00008a8b@hotmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
Barry...
Yes I know there is some code duplication from the ResultSet class.
I thought about several options and chose this one. I can easily
rework it to one of the following options:
1) Break the formatting code out of ResultSet into a utility class
having a bunch of static methods.
2) Create new static methods in ResultSet that format the data.
Wasn't sure how this would be received since it added methods to the
java.sql.ResultSet interface implementation. (i.e. how "pure" should
the ResultSet class be?)
As for the OID issue, I followed the DatabaseMetaData.java example in
hardcoding OIDs. I did this because the proper SQL type for any array
is simply ARRAY (not very useful). I will look into whether the
Field object can return the proper '_' prefixed type name with minimal
changes (eg. "_int4" is the type name for an array of int4). I could
also invent non-standard specific array SQL types (ARRAY_INT4, etc.)
but I don't like non-standard. It's really a shame that SQL types aren't
more specific with arrays.
Your thoughts?
Thanks
Greg
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp