From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | pg(at)fastcrypt(dot)com |
Cc: | "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: PreparedStatement parameters and mutable objects |
Date: | 2004-01-08 22:56:25 |
Message-ID: | 3FFDE019.4090005@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan Purvis | 2004-01-09 03:01:34 | JDBC driver doesn't handle NaN values |
Previous Message | agiwa | 2004-01-08 16:58:48 | Multi-dimensional array support |