Re: PreparedStatement parameters and mutable objects - Mailing list pgsql-jdbc

Ah, yes, my bad, tested wrong. Whenever I use the word 'idiot' in post
it ends up pointing back to me...

Oracle produces {1,2,3} with the following:

        byte[] b = new byte[] {(byte)1,(byte)2,(byte)3};
        stmnt.setInt(1,1);
        stmnt.setBytes(2,b);
        b[2] = (byte) 33;
        stmnt.executeUpdate();

So its doing it at the actual 'setXXX' call.



On Jan 9, 2004, at 9:37 AM, Dave Cramer wrote:

> Andrew,
>
> What happens in Oracle if he second setBytes is not called?
> does it still insert {1,2,33} ?
>
> I think my biggest concern is Andrew's last statement:
> "Ambiguity tends to have to favor the idiot, unfortunately"
>
>
> Dave
>
> On Fri, 2004-01-09 at 09:28, Andrew Rawnsley wrote:
>> If anyone is looking for behavior from others, Oracle (my apologies
>> for
>> using the 'O' word...) behaves like this:
>>
>>         byte[] b = new byte[] {(byte)1,(byte)2,(byte)3};
>>         stmnt.setBytes(1,b);
>>         b[2] = (byte) 33;
>>         stmnt.setBytes(1,b);
>>         stmnt.execute();
>>
>> results in {1,2,33}. (Disclaimer - I'm not advocating something just
>> because 'Oracle does it this way')
>>
>> Why someone would do this is, of course, I don't know.
>>
>> While I am all for the idea of improved performance, I find myself
>> forced to agree with the idea that, while something
>> like the above is kooky, it isn't illegal, and falls into the realm of
>> expected (but not necessarily mandated) behavior from a driver.
>> Ambiguity tends to have to favor the idiot, unfortunately.
>>
>> On Jan 9, 2004, at 8:46 AM, Dave Cramer wrote:
>>
>>> Well there is some hint that this is incorrect:
>>>
>>>
>>> pstmnt = con.prepareStatment("insert into foo values(?,?)");
>>>
>>> pstmnt.setString(1,"abcd");
>>>
>>> for( i=0; i< 5; i++)
>>> {
>>>     Integer intx = new Integer(i);
>>>     pstmnt.setInt(2,intx)
>>>     pstmnt.executeUpdate();
>>> }
>>>
>>> The above code should insert ("abcd", 0 .. 4 ) into five rows
>>>
>>> The point being that the value for setXXX does not change until
>>> setXXX
>>> is called.
>>>
>>> This is from section 24.1.2 in the JDBC api tutorial
>>>
>>> In all I'm sort of sitting on the fence here. I guess we could try it
>>> and see how many people get tripped up?
>>>
>>> Dave
>>>
>>> On Fri, 2004-01-09 at 03:18, Kris Jurka wrote:
>>>> On Fri, 9 Jan 2004, Oliver Jowett wrote:
>>>>
>>>>>> I'm saying that doing it this way will likely expose buggy code,
>>>>>> which
>>>>>> we will end up having to figure out why it doesn't work, when the
>>>>>> user
>>>>>> says "my code used to work, and now it doesn't", plus they don't
>>>>>> send us
>>>>>> code to look at.
>>>>>
>>>>> How far do we go to support buggy code though? If we can't make
>>>>> this
>>>>> sort of change, we lose several opportunities for optimization.
>>>>
>>>> I don't think you can label this as buggy code unless you can point
>>>> to the
>>>> spec and say where it is disallowed.  It is certainly something that
>>>> looks
>>>> dangerous and is unlikely to be written by the average developer,
>>>> but
>>>> that
>>>> doesn't make it illegal.  I lean towards the notion that when I say
>>>> setXXX
>>>> that's the time the value must be saved because that's certainly
>>>> more
>>>> intuitive and specific than "sometime later when the driver decides
>>>> to."
>>>>
>>>> Kris Jurka
>>>>
>>>>
>>>> ---------------------------(end of
>>>> broadcast)---------------------------
>>>> TIP 4: Don't 'kill -9' the postmaster
>>>>
>>> --
>>> Dave Cramer
>>> 519 939 0336
>>> ICQ # 1467551
>>>
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 5: Have you checked our extensive FAQ?
>>>
>>>                http://www.postgresql.org/docs/faqs/FAQ.html
>>>
>> --------------------
>>
>> Andrew Rawnsley
>> President
>> The Ravensfield Digital Resource Group, Ltd.
>> (740) 587-0114
>> www.ravensfield.com
>>
> --
> Dave Cramer
> 519 939 0336
> ICQ # 1467551
>
--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com