Sorry, the error does not seem to be in the ResultSet but instead in the Callable Statement, method execute().

java.lang.NullPointerException
at
org.postgresql.core.v3.SimpleParameterList.getV3Le ngth(SimpleParameterList.java:228)
at
org.postgresql.core.v3.QueryExecutorImpl.sendBind( QueryExecutorImpl.java:807)
at
org.postgresql.core.v3.QueryExecutorImpl.sendOneQu ery(QueryExecutorImpl.java:1052)
at
org.postgresql.core.v3.QueryExecutorImpl.sendQuery (QueryExecutorImpl.java:643)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(Q ueryExecutorImpl.java:189)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execut e(AbstractJdbc2Statement.java:452)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execut eWithFlags(AbstractJdbc2Statement.java:351)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execut e(AbstractJdbc2Statement.java:344)

On Thu, 27 Sep 2007, Ludovico Bianchini wrote:

> Sorry, the error does not seem to be in the ResultSet but instead in the
> Callable Statement, method execute().
>
> java.lang.NullPointerException
> at
> org.postgresql.core.v3.SimpleParameterList.getV3Le ngth(SimpleParameterList.java:228)
> at
> org.postgresql.core.v3.QueryExecutorImpl.sendBind( QueryExecutorImpl.java:807)

It is likely failing at execution number 6 because that's the point where
the driver switches over to using server prepared statements instead of
executing things on the fly. I don't have time to take a look at this
now, but it's likely a driver problem. Hopefully I'll be able to look at
this on Sunday/Monday.

Kris Jurka


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Kris Jurka wrote:
>
>
> On Thu, 27 Sep 2007, Ludovico Bianchini wrote:
>
>> Sorry, the error does not seem to be in the ResultSet but instead in
>> the Callable Statement, method execute().
>>
>> java.lang.NullPointerException
>> at
>> org.postgresql.core.v3.SimpleParameterList.getV3Le ngth(SimpleParameterList.java:228)
>>
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.sendBind( QueryExecutorImpl.java:807)
>>
>
> It is likely failing at execution number 6 because that's the point
> where the driver switches over to using server prepared statements
> instead of executing things on the fly. I don't have time to take a
> look at this now, but it's likely a driver problem. Hopefully I'll be
> able to look at this on Sunday/Monday.

If this is the case, couldn't he use "?prepareThreshold=0" at the end of
his connect URL as a temporary workaround? It will be slower, but it
would unblock him.

Regards,
Eric Faulhaber

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Thu, 27 Sep 2007, Eric Faulhaber wrote:

> If this is the case, couldn't he use "?prepareThreshold=0" at the end of his
> connect URL as a temporary workaround? It will be slower, but it would
> unblock him.
>

Yes, but it's pretty much equivalent to his current workaround of creating
a new CallableStatement object inside the loop and that doesn't affect
other queries.

Kris Jurka


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Mon, 1 Oct 2007, Kris Jurka wrote:

> I've managed to reproduce this problem with the attached test case.
> At fault are the ill conceived side effects in
> org.postgresql.core.v3.SimpleParameterList#getType OID. An accessor
> like getTypeOID shouldn't be responsible for setting a value for the
> out parameter. getTypeOID is called from QueryExecutorImpl's
> sendParse method, which obviously isn't called when we reuse a server
> side prepared statement and don't need to reparse. This leaves an
> uninitialized value in the paramValues array which we die on later.
>

I've applied a fix for this in CVS to 8.1, 8.2 and 8.3dev and it will be
included in the next release.

Kris Jurka

---------------------------(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