Dave Cramer wrote:
> You're on fairly shaky ground using "allowed by the spec" as
> justification.
Why's that? Are we no longer trying to write a spec-compliant driver?
> I'm thinking there are far more instances where people
> expect Oid unspecified to work than
> instances where they are going to change the type of the IN parameter
> in the same statement.
Sure, but I'd rather not have an option that makes the driver break
unexpectedly. Given that we can have both unspecified string types AND a
fix for the changing-type problem, why do you *not* want to do that?
If you want a more "real world" example, how about something like this:
>> ArrayList toInsert = new ArrayList();
>> toInsert.add(new Integer(42));
>> toInsert.add(new Date());
>> toInsert.add("test string");
>> // ...
>> PreparedStatement ps = conn.prepareStatement("INSERT INTO sometexttable(sometextcolumn) VALUES (CAST (? AS TEXT))");
>> for (Iterator i = toInsert.iterator(); i.hasNext(); ) {
>> ps.setObject(1, i.next());
>> ps.executeUpdate();
>> }
Test cases are not meant to be real-world examples, they're test code.
Use your imagination!
> Given that the default behaviour adheres to the spec, I'm not too
> worried about the case below failing under these specific
> circumstances. I presume it passes with the 8.0,8.1 behaviour.
It does.
The code I have committed to CVS HEAD deals with the
changing-parameter-type case correctly even with stringtype=unspecified,
anyway. Can you please try it out and see if you have any problems with it?
Otherwise, as far as I'm concerned I'm done with this -- if people don't
want to change their (arguably broken) apps, they have an escape hatch
they can enable explicitly or via compatible=7.4.. IMO we don't need to
do anything more.
-O