From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Inserting "null" not working (Sun App Server, Postgres, EJB3)? |
Date: | 2007-03-02 01:41:39 |
Message-ID: | 9412284C-E14A-4A9E-97C6-F2680457E08F@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Ok, looking at the code in the driver we should be doing the right
thing.
setObject(n,null) will set the Oid to UNSPECIFIED
Any chance we can get a test case to see how this fails ?
Dave
On 1-Mar-07, at 8:15 PM, Dave Cramer wrote:
>
> On 1-Mar-07, at 7:16 PM, Tom Lane wrote:
>
>> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>>> On 1-Mar-07, at 7:06 PM, Tom Lane wrote:
>>>> At least in this particular case, leaving the parameter type as
>>>> UNKNOWN
>>>> would have worked as the OP wishes. I dunno if that would break
>>>> other
>>>> cases though.
>>
>>> This means you have to leave all parameter types as UNKNOWN. What's
>>> the point of having parameter types at all ?
>>
>> No, only the ones you do not have any knowledge about. The OP's
>> complaint is basically that the driver is forcing the parameter type
>> to "varchar" on the basis of nothing whatsoever.
>>
> OK, this makes some sense, If they do setObject(n, null) then we
> bind the type to UNKNOWN. If they do setInt(n, null) we can
> actually get that one right.
>
> Dave
>> regards, tom lane
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 2: Don't 'kill -9' the postmaster
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2007-03-02 01:59:29 | Re: statement caching proof of concept redux |
Previous Message | Oliver Jowett | 2007-03-02 01:39:50 | Re: Inserting "null" not working (Sun App Server, Postgres, EJB3)? |