Re: setObject on PGInterval throws "Unknown Type null"

With JDBC Build 309,
pstmt.setObject(i, x)
has to be replaced by

if (x == null) pstmt.setNull(i, Types.SomeType) else pstmt.setObject(i, x)
which may be simplified as

pstmt.setObject(i, x, Types.SomeType)

That's what I was referring to when I said that setObject(i, x) has been
rendered useless

The type information could be provided regardless of null by a method
specific to each class.
It could use new method names or be overloaded versions of setObject

for PGInterval, it could also hide SQL null => new PGInterval

public void setObject(int parameterIndex, PGInterval x)
throws SQLException
{
this.setObject(parameterIndex, x == null ? new PGInterval() : x);
}

These methods could also be available for jdbc buil-in types

public void setObject(int parameterIndex, Integer x)
throws SQLException
{
this.setObject(parameterIndex, x, Types.INTEGER);
}

public void setObject(int parameterIndex, String x)
throws SQLException
{
this.setObject(parameterIndex, x, Types.VARCHAR); // could also be
this.setString(parameterIndex, x);
}

I understand that this is not standard JDBC, but as you guys highlighted,
there is no provision
in the standard for supplying type with null values on extended types. Plus
it would provide some form
of backward compatibility for setObject(i,x)

Jean-Pierre Pelletier

----- Original Message -----
From: "Oliver Jowett" <oliver(at)opencloud(dot)com>
To: "Kris Jurka" <books(at)ejurka(dot)com>
Cc: "Jean-Pierre Pelletier" <pelletier_32(at)sympatico(dot)ca>;
<pgsql-jdbc(at)postgresql(dot)org>
Sent: Tuesday, January 25, 2005 6:33 PM
Subject: Re: [JDBC] setObject on PGInterval throws "Unknown Type null"

> Kris Jurka wrote:
>>
>> On Wed, 26 Jan 2005, Oliver Jowett wrote:
>>
>>
>>>What about when we prepare a statement with a null parameter, then later
>>>use it with a non-null parameter? There is some protocol code needed here
>>>to get the inferred types back.
>>>
>>>We currently break in the case where parameter types change between
>>>executions, but that's more easily fixable since we have all the
>>>necessary information already available.
>>>
>>
>>
>> I'm not sure I'm willing to make that distinction, they seem like the
>> same thing to me. If we fixed the second case and found the solution to
>> the first intractable then you could make the case to require typed
>> nulls, but since the second case is broken that argument doesn't carry a
>> lot of weight with me.
>
> It's not unfixable, it just means there is more work required to fix the
> existing brokenness.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster