On Thu, 17 Nov 2005, pedro farinha wrote:
> I am testing the new JSC2 early access and I come across a old
> problem....getResultMetaData null values (I think). In JSC 1 the driver
> works fine but on this early access version it doesn't. I am posting
> what I think is relevant of the trace. I am not sure if this is a issue
> with the driver or the JSC it self so I am posting this into here as
> well as into the EAfeedback program.
>
> java.lang.RuntimeException: java.sql.SQLException: Invalid column
> display size. Cannot be less than zero
> at
> com.sun.data.provider.impl.CachedRowSetDataProvider.getMetaData(CachedRowSetDataProvider.java:1299)
I believe you have a variable length field in your table. Sun's
CachedRowSet implementation examines the ResultSetMetaData and creates its
own copy of it. The postgresql JDBC driver returns -1 for
ResultSetMetaData.getColumnDisplaySize() meaning unknown for variable
length fields, like say a column of type "text". Sun does not like this
value and reports an error. In the past we've tried to ask Sun for some
advice in this area and got nothing in response. Other than -1 the
only other real defensible value for getColumnDisplaySize would
probably be Integer.MAX_VALUE. We've been concerned that GUIs would
try to actually use this provided value and they would blow up, but
the only complaints we've heard are from people disliking the -1
value and this problem doesn't seem to be going away.
I suggest we try returning Integer.MAX_VALUE for a while and see what
complaints we get. Objections?
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
"the normal maximum number of characters allowed as the width
of the designated column"
Any GUI app should be prepared to truncate or wrap large values.
-Kevin
>>> Kris Jurka <bo...@ejurka.com> >>>
On Thu, 17 Nov 2005, pedro farinha wrote:
I believe you have a variable length field in your table. Sun's
CachedRowSet implementation examines the ResultSetMetaData and creates
its
own copy of it. The postgresql JDBC driver returns -1 for
ResultSetMetaData.getColumnDisplaySize() meaning unknown for variable
length fields, like say a column of type "text". Sun does not like this
value and reports an error. In the past we've tried to ask Sun for some
advice in this area and got nothing in response. Other than -1 the
only other real defensible value for getColumnDisplaySize would
probably be Integer.MAX_VALUE. We've been concerned that GUIs would
try to actually use this provided value and they would blow up, but
the only complaints we've heard are from people disliking the -1
value and this problem doesn't seem to be going away.
I suggest we try returning Integer.MAX_VALUE for a while and see what
complaints we get. Objections?
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
On Fri, 18 Nov 2005, Kris Jurka wrote:
> [People don't like -1 for getColumnDisplaySize()]
>
> I suggest we try returning Integer.MAX_VALUE for a while and see what
> complaints we get. Objections?
>
I've adjusted this in cvs. Please try out one of these jars and let us
know how that works out.
http://ejurka.com/pgsql/jars/pf/
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
On Fri, 25 Nov 2005, pedro farinha wrote:
> Can you tell me if this fix (if that) will be included in the cvs? or in
> a snapshot? I would like to make a reference to it on the Sun forum.
Yes, this has been added in cvs, but I've yet to produce a new development
release. Due to some other driver events I'll put out a new dev release
on the official website in the next few days.
> One other issue:
> On the early-access feedback discussion there are some issues relating
> with changing the transaction isolation level in the middle of the
> transaction. You know anything about it?
>
See this message for an explanation:
http://archives.postgresql.org/pgsql-jdbc/2005-11/msg00112.php
I believe the spec suggested deferring the changing of isolation levels
until the next transaction begins, but we decided that could mask serious
coding errors because the isolation level wasn't actually changing at the
time of the call. Revisiting this is an option, but it still seems like a
bad idea to me.
Kris Jurka
---------------------------(end of broadcast)---------------------------