Kris Jurka wrote:
>
> On Sat, 9 Oct 2004, Oliver Jowett wrote:
>
>
>>Oliver Jowett wrote:
>>
>>>I am currently cleaning up a few places where OID 0 could get used as a
>>>parameter type (causing the backend to try to infer a type).
>>
>>Here is a patch to do this, including the PGobject changes to handle SQL
>>NULLs.
>>
>
>
> What I was suggesting before was a means to allow users to specify a pg
> type for the Types.OTHER case, but not to require it. I don't see the
> danger in allowing OID 0 in this case.
Ah, I thought you were OK with disallowing setNull(Types.OTHER)
entirely, I must have misunderstood what you said earlier.
I described one problem with allowing it in an earlier email:
>> Consider the case where you have two functions:
>>
>> foo(line)
>> foo(box)
>>
>> Executing "SELECT foo(?)" via PreparedStatement will work fine if you pass a non-null PGline or PGbox argument to
setObject,but if you try to setNull() then you will get ambiguity between the two functions at execution time.
That's quite unpredictable behaviour.
> I know you are after complete
> strong typing, but I don't see the benefit while I do see the drawback.
What is the drawback? The only case that will change is the case that is
currently ambiguous. And there is a fairly simple mechanism for
disambiguating it via PGobject.
-O