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

From Oliver Jowett
Subject Re: PreparedStatement parameters and mutable objects
Date
Msg-id 3FFDE019.4090005@opencloud.com
Whole thread Raw
In response to Re: PreparedStatement parameters and mutable objects  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: PreparedStatement parameters and mutable objects  (Kris Jurka <books@ejurka.com>)
List pgsql-jdbc
Dave Cramer wrote:
> On Thu, 2004-01-08 at 01:03, Oliver Jowett wrote:
>
>>Dave Cramer wrote:
>>
>>>Oliver,
>>>
>>>while I think the code snippet below has defined behaviour
>>
>>What is the defined behaviour, then? It's not obvious to me whether
>>{1,2,3}, {42,2,3}, or a driver-dependent value (i.e. undefined
>>behaviour) gets inserted.
>
> defined by who, I meant it was defined in that it didn't have any
> surprises. If you implement your idea, then 42,2,3 will be inserted
> otherwise 1,2,3

Ok. I meant "defined by the JDBC spec" i.e. portable between drivers. It
sounds like you think it's undefined in this sense.

> 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.

If the only objection is supporting buggy code, I'll probably do the
changes anyway and apply the patch locally even if it doesn't hit CVS,
since we don't have buggy code here ;)

-O

pgsql-jdbc by date:

Previous
From: Barry Lind
Date:
Subject: Re: getBytes() returning too much data
Next
From: "Antonio Gallardo"
Date:
Subject: [BUG] - Invalid UNICODE character sequence found (0xc000)