> AFAIK this is just business as usual with JDBC: setString() implies that > the parameter is of a string type. It'll fall over if the type actually > required is anything but a string. (I'm no Java expert, but I seem to > recall that using setObject instead is the standard workaround.) > > Enums are not suffering any special hardship here, and I'd be against > weakening the type system to give them a special pass.
Yes, you can use setObject(1, "enumval", Types.OTHER). I was hoping that setString might work, as mapping java enum values to strings in the database is a very common ORM technique that is built into basically all major ORMs including all that support the JPA standard, and it leads to people using varchars instead of typesafe enums in their dbs. If setString worked, people could migrate their schemas to the typesafe versions without touching any code. Using setObject people need to write a custom converter in most of those systems, and configure its use for each enum that they have. This then also makes swapping database backends difficult (for people who care about that sort of thing), since the jdbc calls are now different for postgresql vs anything else.
Anyway, if there's no nice way to do it in the backend without adding implicit casts, and you're not happy with the costs of that as a solution, I guess that's that. I guess I was hoping that a text value parameter to a prepared statement could be treated as input when the type didn't match, but I don't know if that's feasible, and I guess it's probably opening the door to confusing error messages when someone provides the wrong type accidentally.