Re: PreparedStatement parameters and mutable objects

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

In response to

Responses

Browse pgsql-jdbc by date

  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