Обсуждение: Error reporting issue in SimpleParameterList

On Wed, 13 Jun 2007, Nathan.Keynes@csiro.au wrote:

> In org.postgresql.core.v3.SimpleParameterList there is the following
> code:
>
>    void setResolvedType(int index, int oid) {
>        // only allow overwriting an unknown value
>        if (paramTypes[index-1] == Oid.UNSPECIFIED) {
>            paramTypes[index-1] = oid;
>        } else if (paramTypes[index-1] != oid) {
>            throw new IllegalArgumentException("Can't change resolved
> type for param: " + index + " from " + paramTypes[index] + " to " +
> oid);
>        }
>    }
>
> In the throw statement, paramTypes[index] should be paramTypes[index-1].
> (This was a little confusing until we spotted it).

Fix applied to CVS for 8.0, 8.1, 8.2, and 8.3dev.

> It's possible the message could be more explanatory as well, would
> something like "Param " + index + " type mismatch - expected " +
> getNameForOid(oid) + " but was bound to " +
> getNameForOid(paramTypes[index-1])  make sense?
>

Getting the names for the oids is tough from this part of the code so I
don't think we can do that.  Also I think this is supposed to be a "can't
happen" error that's more of an assert than a message for an end user.
Do you have an example of how to trigger this condition?

Kris Jurka

> Getting the names for the oids is tough from this part of the
> code so I
> don't think we can do that.  Also I think this is supposed to
> be a "can't
> happen" error that's more of an assert than a message for an
> end user.
> Do you have an example of how to trigger this condition?

Hi Kris,

   I've been trying to put together a minimal example of what we were
doing to trigger it, but unfortunately I haven't been able to reproduce
it outside of the original (too large for a test case) dataset yet. We
did trace it to code that was conceptually something like this:

    stmt.executeUpdate("create table TEMP1 ( value1 BIGINT )" );
    conn.commit();
    PreparedStatement ps = conn.prepareStatement("insert into TEMP1
(value1) values (?)");
    ps.setObject( 1, new Integer(123) );
    ps.addBatch();
    ps.setNull( 1, Types.BIGINT );
    ps.addBatch();
    ps.executeBatch();
    ps.setNull( 1, Types.BIGINT );
    ps.addBatch();
    ps.setObject( 1, new Integer(234) );
    ps.addBatch();
    ps.executeBatch();

   Basically, batch inserts with a BIGINT column, and mixing setObject()
with Integer values with setNull with explicit BIGINT type. The code
fell over on the second executeBatch() although there was no apparent
distinction between the batches for the column it complained about.
Changing the setObject call to eg
    setObject( 1, new Integer(123), Types.BIGINT );
did fix the problem for us - at the time I assumed that the code was
complaining about the mixing of INT4 with INT8 in the batch, but it's
looking like there was more to it than that.

   This was using Postgres 8.2.3, JDBC driver 8.2-504.

   I don't know if the above is particularly helpful - I'll follow up
if/when I can get a reliable test case to reproduce.

Cheers,
Nathan

On Thu, 21 Jun 2007, Nathan.Keynes@csiro.au wrote:

>   I've been trying to put together a minimal example of what we were
> doing to trigger it, but unfortunately I haven't been able to reproduce
> it outside of the original (too large for a test case) dataset yet. We
> did trace it to code that was conceptually something like this:
>

I can't trigger it either.  What might help is running your original code
with driver logging turned on.  Add ?loglevel=2 to your JDBC URL and it
will log everything the driver is doing behind the scenes.  From this
perhaps we can see where the driver is getting confused.

Kris Jurka