Re: IN clauses via setObject(Collection) [Was: Re: Prepared

Felipe Schnack wrote:
>   Well, that's your opinion, calm down :-)
>   Anyway, I really think the solution of add various parameter marks ("?") and fill the ones you don't use with nulls
israther awful. There is a database that provides another solution for that? 
>

Not DB2 nor Oracle.  Only PostgreSQL 7.4 and with the planner
restriction I've mentioned.

Fernando

P.S.: Although I agree that any extension to the standard must be very
carefully thought, the PostgreSQL community has been very successful at
being less restrictive and has actually improved the behavior compared
to the standard.  So, if we can come up with a sensible way of filling
the <in values list> of the IN <predicate> I believe we should.

But _never_ leaving a security hole or in a way that clearly will break
possible future expansions of the JDBC.



> On Tue, 22 Jul 2003 09:34:10 +0100
> Paul Thomas <paul@tmsl.demon.co.uk> wrote:
>
>
>>On 21/07/2003 18:51 Fernando Nasser wrote:
>>
>>>Also, we may limit this behavior with Collections to the IN clause
>>>only.  Where else could we need lists to replace the '?' ?
>>
>>Nowhere. Not even with an IN clause. If the programmer needs IN(1,2,3,4,5)
>>then he must write IN(?,?,?,?,?) in his prepare string. That's the way
>>JDBC works. Period. Acceptance of any other behaviour is un-professional
>>and against the standards. As you said yourself, neither Oracle nor DB2
>>support this behavior. Neither should PostgreSQL.
>>
>>
>>--
>>Paul Thomas
>>+------------------------------+---------------------------------------------+
>>| Thomas Micro Systems Limited | Software Solutions for the Smaller
>>Business |
>>| Computer Consultants         |
>>http://www.thomas-micro-systems-ltd.co.uk   |
>>+------------------------------+---------------------------------------------+
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 9: the planner will ignore your desire to choose an index scan if your
>>      joining column's datatypes do not match
>
>
>


--
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9