Re: PreparedStatement parameters and mutable objects
От | Andrew Rawnsley |
---|---|
Тема | Re: PreparedStatement parameters and mutable objects |
Дата | |
Msg-id | 20930F3C-42B0-11D8-9B94-000393A47FCC@ravensfield.com обсуждение исходный текст |
Ответ на | Re: PreparedStatement parameters and mutable objects (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: PreparedStatement parameters and mutable objects
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Csaba NagyДата:
Сообщение: Re: [BUG] - Invalid UNICODE character sequence found(0xc000)
Следующее
От: Csaba NagyДата:
Сообщение: Re: [BUG] - Invalid UNICODE character sequence found(0xc000)